Langue

Solutions de sécurité à plate-forme ouverte : Gérer les attentes des clients

Cet article a été publié à l'origine sur SecurityInformed.com.

PAR DAVID FLEMING

Il n'est pas difficile de comprendre pourquoi de plus en plus de sites demandent des solutions de sécurité qui fonctionnent sur un système ouvert. La sélection de produits et de plates-formes qui utilisent des normes ouvertes - protocole d'initiation de session (SIP), HTTP, IEEE, API RESTful, etc. - offre des niveaux supplémentaires d'interopérabilité, d'évolutivité et de polyvalence qui donnent aux organisations la flexibilité qu'elles souhaitent pour être proactives en matière de sûreté et de sécurité.

Malheureusement, créer la bonne solution aujourd'hui n'est pas aussi simple que de lire une fiche produit ou une spécification. Dans le passé, les utilisateurs finaux étaient souvent contraints de choisir des produits matériels et logiciels qui étaient la propriété de chaque fabricant, ce qui signifie que les éléments technologiques n'avaient souvent pas la capacité de communiquer et d'interagir avec des produits qui ne portaient pas le même nom de marque.

À l'avenir, tous les systèmes seront probablement ouverts sous une forme ou une autre et offriront une multitude d'options de connectivité avec peu ou pas de temps et de ressources de développement supplémentaires.

Mais en attendant ce jour, il est important de gérer correctement les attentes des parties prenantes au projet, sachant que le paysage actuel de la sécurité n'a pas encore évolué au point que tous les systèmes soient réellement ouverts.

Attentes des consommateurs en matière de technologie

Pour être juste, les attentes de l'utilisateur final sont souvent déterminées par ce qu'il voit se produire avec la technologie grand public et non par ce qui est actuellement disponible sur le marché de la sécurité. Dans ce domaine, les avancées technologiques peuvent sembler se produire du jour au lendemain. Les applications de votre smartphone, par exemple, effectuent des mises à jour quasi instantanées, même lorsque vous ne l'utilisez pas activement.

Aussi pratique que cela puisse être avec les médias sociaux ou les applications de jeu, cela peut également signaler un système qui nécessite régulièrement des corrections et des correctifs, un scénario qui ne fournirait pas aux parties prenantes le niveau avancé de fiabilité qui est exigé pour une sécurité adéquate avec des produits de sécurité commerciale, en grande partie parce qu'il exposerait les lieux à de nombreux problèmes de responsabilité. En conséquence, l'espace de sécurité actuel peut ressembler à son passé presque autant qu'à son avenir.

Diminution du potentiel de compatibilité

Ne vous y trompez pas, il existe aujourd'hui de nombreux produits qui peuvent facilement s'intégrer dans des plates-formes ouvertes, mais seulement dans une capacité plus limitée. Un téléphone de bureau IP, par exemple, peut facilement se connecter à un autre système PBX IP qui peut alors passer des appels de base.

Mais à mesure que la demande du client pour des options sophistiquées supplémentaires augmente - diagnostics, déclenchements d'événements, identification de l'emplacement, etc. En matière de sécurité, cela est dû au fait que deux produits ou systèmes exposent rarement des fonctionnalités similaires en utilisant la même technologie ou le même langage.

Prenons l'exemple suivant : Le fabricant A vend un produit qui contient les caractéristiques X et Y ; le fabricant B en propose un qui contient les caractéristiques Y et Z. Le client suppose donc - ou peut même se voir vendre - une solution dans laquelle X, Y et Z peuvent toutes être configurées.

L'association des deux peut vous permettre d'obtenir assez facilement l'interopérabilité avec la fonctionnalité Y (si elles sont mises en œuvre de la même manière), mais X et Z ne seront pas possibles sans un investissement supplémentaire qu'il peut être difficile d'obtenir.

Répondre aux attentes des utilisateurs finaux

Cependant, le diable se cache dans les détails, un message qui n'est pas toujours communiqué efficacement aux utilisateurs finaux. Le fait d'invoquer le vieil adage "Pour moi, c'est du grec" ne fait que préparer le projet à des révisions ultérieures potentiellement coûteuses - des coûts que l'intégrateur doit souvent prendre en charge. Il est donc dans l'intérêt de toutes les parties d'avoir une compréhension commune du projet dès le début.

Compte tenu de l'état actuel du marché de la consommation, il est essentiel que les intégrateurs comprennent la réalité des produits qu'ils envisagent avant de rechercher des solutions potentielles.

De nombreux fabricants proposent une liste de "partenaires d'intégration" avec lesquels ils sont compatibles, mais ces scénarios ont une portée prédéfinie qui peut ne pas correspondre aux attentes de l'utilisateur final.

Évaluer la compatibilité

Pour comprendre toutes les options disponibles, il faut demander une copie du kit de développement logiciel (SDK) du fabricant, qui devrait contenir des informations détaillées sur les possibilités d'intégration avec ses produits.

À partir de là, vous pouvez comparer les appareils envisagés pour voir s'ils sont compatibles les uns avec les autres. Enfin, il est important de tenir compte des implications pratiques du financement. Si l'utilisateur final recherche des fonctionnalités qui ne sont pas possibles actuellement, il faudra alors passer un contrat de développement supplémentaire pour y parvenir.

Certains fabricants proposent des services de conception avec des développeurs habitués à leurs plateformes, ce qui peut contribuer à accélérer la courbe d'apprentissage.

Cependant, avec le bon SDK et une bonne connaissance des plateformes utilisées, une société de développement tierce ou un entrepreneur est tout à fait capable de fournir le même niveau de travail que le fabricant.

Considérations relatives à l'intégration des systèmes de sécurité

Pour rappel, toute intégration, quelle qu'en soit l'ampleur, nécessite de se poser les trois questions suivantes :

  1. Que veut l'utilisateur final ?
  2. Que peuvent faire les produits aujourd'hui ?
  3. Comment combler le fossé ?

Il est impératif que les intégrateurs et les utilisateurs finaux prennent le temps de répondre à ces trois questions clés afin de s'assurer qu'ils choisissent une solution qui non seulement fonctionnera demain, mais qui fournira également un niveau de protection approprié pour les personnes et les biens aujourd'hui.

Cela devrait également permettre d'atténuer la confusion ou la frustration que pourrait ressentir le client. Même si nous aimerions tous croire que chaque fonctionnalité disponible est une option viable, ce n'est tout simplement pas possible compte tenu des réalités auxquelles nous sommes confrontés aujourd'hui.

Un jour viendra où les avancées technologiques dont bénéficient les consommateurs du monde entier permettront d'appliquer ce type d'expérience à la sécurité.

En attendant, chaque partie impliquée dans le projet doit comprendre exactement ce qui est disponible actuellement du point de vue du matériel et des logiciels. La sécurité de toutes les personnes présentes sur le site en dépend.

David Fleming est le directeur de la conception de Code Blue Corporation.