Le mois dernier, PagerDuty et Pile de menaces se sont réunis à Seattle pour co-organiser un atelier — « La gestion des incidents au XXIe siècle En tant que directeur principal des opérations et du support chez Threat Stack, j'ai eu le plaisir de m'entretenir avec Jonathan Wilkinson, vice-président produit de PagerDuty, au sujet de la sécurité du cloud et de la gestion des incidents.

Le point commun de nos deux interventions était la manière dont les entreprises peuvent informer rapidement et efficacement les personnes concernées lorsqu'un incident important survient, en incitant les équipes d'exploitation, de sécurité et de développement à collaborer plus étroitement.

Vous voyez, tout comme les équipes sont averties lorsqu'un site web est hors service, le même processus s'applique lorsqu'un site web est piraté. Dans le contexte actuel de la sécurité, les organisations peuvent appliquer efficacement leurs processus d'alerte PagerDuty existants aux problèmes de sécurité. La meilleure façon d'y parvenir est de mettre en place une culture de la sécurité qui favorise des alertes, une escalade et une collaboration efficaces. C'est d'ailleurs l'une des principales raisons pour lesquelles PagerDuty et Threat Stack ont ​​récemment… a annoncé une intégration qui permet aux clients de gérer les incidents de sécurité du cloud, tels que les connexions des utilisateurs, les processus suspects en cours d'exécution et les modifications de configuration, au sein de PagerDuty.

Un point sur lequel nous nous sommes tous accordés lors de l'atelier est que, face à l'évolution rapide des menaces actuelles, une culture axée sur la sécurité n'est plus un luxe, mais une nécessité. Chez Threat Stack, nous avons très tôt fait le choix d'adopter une telle culture en intégrant nos équipes sécurité, ITOps et DevOps. Voici quelques enseignements tirés de notre expérience en matière de développement de cette culture, ainsi qu'un aperçu de la manière dont nous l'avons mise en œuvre.

La meilleure culture de sécurité est collaborative, et non prescriptive.

Amener toute une équipe à comprendre la sécurité et la gestion des incidents représente un défi de taille. Les équipes ITOps et DevOps sont désormais confrontées à des questions inédites, autrefois considérées comme relevant exclusivement de l'« équipe de sécurité ».

Voici quelques-unes des questions les plus fréquemment posées :

• Comment pouvons-nous devenir plus proactifs en matière de sécurité des applications ?
• Comment construire des systèmes « sécurisés par défaut » ?
• Quels sont les meilleurs outils à utiliser pour accomplir tout cela ?
• Comment puis-je informer les bonnes personnes, avec les bonnes informations, dans les plus brefs délais ?

La sécurité doit être aussi intégrée et collaborative que possible, et non rigide et prescriptive. Mais que faire si vous n'avez pas d'équipe de sécurité dédiée ? Ou si vous êtes une petite startup aux ressources limitées ? En réalité, en matière de sécurité, nous sommes tous confrontés aux mêmes contraintes de temps et de ressources, quelle que soit la taille de notre équipe, et nous aspirons tous à la même chose : une meilleure sécurité. En fait, adopter des politiques de sécurité modernes n'est pas si différent d'adopter les pratiques DevOps. En intégrant la surveillance aux flux de travail quotidiens, les équipes de sécurité, DevOps et ITOps peuvent obtenir les informations détaillées sur les services, les utilisateurs et les activités dont elles ont besoin pour garantir la sécurité des applications. De nombreuses entreprises ont déjà une expérience en la matière. intégration des méthodologies DevOps — GE Capital , Macy's, Cible , et Nordstrom Ces entreprises ont été parmi les toutes premières à adopter le DevOps. Confrontées à des silos organisationnels puissants et profondément enracinés, leur succès reposait sur la mise en place de cultures collaboratives. Les mêmes principes peuvent être appliqués à la mise en œuvre d'une culture axée sur la sécurité. Un autre excellent exemple en est… transformation sur trois ans de la fonction Infosec de Twitter Tout a commencé lorsque le compte @BarackObama a été piraté. C'est une histoire incroyable qui illustre comment ils ont intégré la sécurité au travail quotidien des équipes de développement et d'exploitation, avec pour mission principale de ne pas entraver leur travail.

Les processus de sécurité et la visibilité vont de pair.

Ces dernières années, j'ai discuté avec de nombreux clients de Threat Stack qui souhaitent une meilleure visibilité sur l'activité de leurs systèmes. De même, beaucoup d'équipes d'exploitation le souhaitent également : avoir une vision claire de ce qui se passe sur leur infrastructure. Mais même avec une visibilité optimale, ils ne seront d'aucune utilité s'ils n'ont pas de processus définis pour gérer les événements.

Beaucoup disent : « Ça doit être facile pour vous. Vous pouvez simplement utiliser Threat Stack en interne. » C’est vrai, et nous l’utilisons, mais le fait est que si la culture et les processus internes ne sont pas adaptés aux données fournies par des outils comme Threat Stack et PagerDuty , autant ne pas les utiliser (même si, il faut l’avouer, nous espérons que vous le faites). On peut donc affirmer sans risque que tenter d’intégrer de force des outils obsolètes (un NIDS, par exemple ?) dans un environnement cloud natif plus moderne engendrerait des difficultés inutiles pour les entreprises.

En développant une culture de la sécurité, notamment grâce au flux de travail fourni par l'intégration de PagerDuty et Threat Stack pour la gestion et la résolution des incidents, nous avons pu réduire notre temps de réponse en automatisant les alertes et les données relatives aux événements de sécurité. Réunir rapidement les bonnes personnes pour évaluer la situation a été un facteur déterminant dans la réduction de notre délai de résolution. Cela nous a permis de nous concentrer sur la réponse et la résolution des problèmes, au lieu de nous enliser dans les détails.

Comment Threat Stack a mis en œuvre une culture axée sur la sécurité

Escalade d'alertes avec PagerDuty

Chez Threat Stack, nous sommes de grands fans de PagerDuty. Personnellement, j'utilise PagerDuty depuis son lancement. On pense souvent à PagerDuty en cas de panne de site web ou d'indisponibilité de la base de données, mais son PagerDuty va bien au-delà. C'est un outil formidable que nous utilisons quotidiennement chez Threat Stack pour les alertes de production, les contrôles d'intégrité, l'analyse de données et d'autres cas d'usage de sécurité personnalisés. Nous le considérons comme l'un de nos outils internes les plus importants et les plus précieux.

PagerDuty nous aide de plusieurs façons chez Threat Stack à mettre en œuvre des processus de sécurité collaboratifs et à haute visibilité :

• Notifications provenant des systèmes de production avec des niveaux de gravité d'alerte élevés
• Planification et remplacements
• Groupes d'escalade par service
• Connexions ou processus suspects en cours d'exécution

Ce son strident et mélancolique de trombone réveille notre équipe, même en pleine nuit, pour nous signaler un problème dans le cloud. Nous entretenons une relation amour-haine avec ce fameux signal d'alerte ; il nous oblige à rester vigilants jour et nuit afin que nous puissions, en équipe, assurer la visibilité et mettre en place des procédures de réponse pour garantir la sécurité de nos applications et systèmes.
Communication ouverte avec Slack

Un autre processus que nous avons mis en œuvre a consisté à intégrer nos alertes de sécurité dans Mou — le même système de messagerie que nous utilisons pour toutes nos communications internes. Désormais, lorsqu'une alerte de sécurité est déclenchée, Threat Stack publie un message dans un canal Slack dédié, permettant à tous les participants de le consulter et d'y répondre. L'avantage principal est de pouvoir échanger en temps réel sur Slack au sujet de l'événement. Du code a-t-il été déployé ? S'agit-il d'une tentative de connexion infructueuse à un serveur ?

Pour l'équipe Threat Stack, la fonctionnalité la plus précieuse de PagerDuty est qu'elle offre un espace pour entamer une conversation et signaler tout problème constaté. Nous pouvons ensuite utiliser Slack pour accuser réception du problème, en discuter et, idéalement, le résoudre rapidement.

Mettre en place un processus, même simple, vaut mieux que rien. Les équipes peuvent ensuite l'adapter à tout moment, notamment à mesure que l'entreprise grandit et évolue. Dans tous les exemples précédents, nous avions besoin d'outils pour implémenter des systèmes sécurisés par défaut, mais aussi d'une culture d'entreprise qui permette à chacun de signaler les problèmes de sécurité et de sensibiliser les autres.

J'encourage toutes les entreprises à commencer à mettre en œuvre une approche similaire afin que nous puissions, en tant que communauté, démontrer de meilleures pratiques en matière de sécurité du cloud.