Edition #27 (janvier 2023) du magazine Cyberun : Automatisation

1. S O M M A I R E
Ne pas confondre vitesse
et précipitation
Il y a encore quelques années, la cybersécurité était essentiellement
une affaire d’artisans : la sécurisation, ou simplement la mise à jour des
serveurs, voire des postes de travail, restait essentiellement du cas par cas.
Avec l’augmentation des attaques, l’industrialisation de la protection
a dû s’étendre aux domaines de la détection, puis de la remédiation,
comme peuvent en témoigner les buzzwords de la cyber (SOAR, XDR,
MDR, zero-trust, etc.).
Entre complexité croissante des attaques et multiplication des biens
à protéger, traiter l’avalanche d’événements de sécurité générés peut
rapidement devenir un problème, en particulier lorsque les compétences
viennent à manquer et que “chaque minute compte”. La solution
semble évidente : automatiser la réponse grâce à des “playbooks”
et de “l’intelligence artificielle”.
Pourtant, automatiser l’ensemble des actions autrefois effectuées
manuellement par les analystes cyber et les équipes Ops est loin d’être
évident. D’une part à cause de l’hétérogénéité et de la complexité des
systèmes et des matériels à analyser et/ou à reconfigurer en temps réel,
d’autre part à cause des silos entre les différents équipes/métiers, qui
limitent la mise en commun des ressources et compétences (ainsi, qui
dispose, par exemple, de cartographies précises et à jour de l’ensemble
de ses systèmes ?). Enfin, si l’erreur humaine peut provoquer des dégâts
considérables, une “mauvaise” automatisation n’est pas sans risque :
elle peut par exemple bloquer des actions légitimes, voire être une porte
d’entrée pour la compromission globale du SI. Comme à chaque
automatisation, l’humain doit trouver une nouvelle place.
Pour y parvenir, les équipes aussi bien informatiques, du développeur
à l’exploitant, que métiers, doivent accepter de mettre la cyber au cœur
de chaque SI et être en mesure d’en rationaliser ensemble chaque étape.
5 idées à retenir…
J A N
2 0 2 3
27
C Y B E R S E C U R I T Y S T R AT E G I E S
c y b e r u n . n e t
Automatisation
L’enquête
Ramener l’humain à la même vitesse que la menace _02
Sécurité opérationnelle, détection et réponse à incident _04
Utiliser les outils du cloud _06
Retours d’expériences
IRCEM automatise sa chaîne de développement _08
Decathlon : gestion des incidents de sécurité cloud _09
Automatiser la Threat Intelligence _10
Les grognements de Cy-Bear _12
Les 10 conseils de nos experts _12
Les attaquants recourent massivement à l’automatisa-
tion pour améliorer la vitesse, la furtivité, la portée...
L’automatisation n’est pas l’apanage de la détection
ou de la réaction : c’est aussi une opportunité de
collecter et diffuser de l’intelligence sur les menaces,
d’améliorer la qualité de développement, de durcir
systématiquement les systèmes…
Pas de magie : les processes doivent être
humainement et précisément documentés avant
de pouvoir les automatiser.
Le cloud et “l’infrastructure as a code” ouvrent de
nouvelles opportunités. Les développeurs, assistés
par des outils ad hoc, doivent aussi devenir des
champions de la sécurité.
En cas de maturité insuffisante des équipes,
les premières tentatives d’automatisation risquent
de ne pas aboutir.

2. GEORGES BOSSERT | CTO, SEKOIA.IO
Les attaquants simplifient l’usage de leurs outils, les automatisent pour
gagner en discrétion, en vitesse, en efficacité. Pour nous protéger,
nous n’avons pas d’autre choix que de faire pareil, et à tous les niveaux !
RAMENER L’HUMAIN À LA MÊME VITESSE
QUE LA MENACE
L’ E N Q U Ê T E
_02 / _03
De l’automatisation à
l’hyper-automatisation
Comme les tâches répétitives peuvent être source d’erreurs
(le fameux “Je sais, mais par habitude, je me trompe”), l’automa-
tisation réduit à la fois le risque et augmente, par la même
occasion, la capacité de traitement.
Dans les années 1980, Jens Rasmussen (in Behavioral model skill-rule-
knowledge) décrit trois contextes pouvant engendrer des erreurs. Les erreurs
que l’on peut associer au “savoir-faire” (“Je sais, mais par habitude, je me trompe
car le contexte est différent du contexte habituel”), celles en liaison avec les
“règles ou procédures” (adaptation de la règle au contexte), ou encore celles en
liaison avec la “connaissance” (manque de connaissances).
Pour les deux premières, la capacité à prendre en compte l’ensemble des para-
mètres possibles et une analyse totale du contexte sont les points clés ; pour la
troisième, c’est l’acquisition des connaissances, de base et avancées. Dans ma
vie professionnelle, j’ai souvent été le témoin d’un autre phénomène que l’on
peut appeler “la croyance”. De ce terme, il faut comprendre que notre capacité
à analyser les choses peut être influencée par ce que “l’on croit savoir”.
Imaginez que vous rencontriez un problème d’accès à un serveur HTTP (disons
Apache Tomcat, pour l’exemple) et, par le passé, vous avez déjà plusieurs fois
essuyé des bugs très particuliers liés au déploiement d’applications J2EE sur
cette stack technologique bien précise. Parce que votre savoir-faire et votre
expérience vous rappellent ces bugs, vous allez peut-être écarter inconsciem-
ment un problème de certificats TLS.
DansledomainedesSecurityOperationsCenters(SOC),leSecurityOrchestration,
Automation and Response (SOAR) accélère le traitement des alertes par la mise
en œuvre d’un niveau d’automatisation variable (de peu automatisé à totalement
automatisé) et dédouane les analystes de tâches fastidieuses de recherche dans
des centaines de journaux d’événements (logs).
Mais l’automatisation, y compris en cybersécurité, a vécu (le SOAR existe depuis
2016) et pour pallier certaines limitations (coûts initiaux élevés pour préparer
l’automatisation, faire évoluer les modèles d’automatisation reste manuel et
demande de la maintenance), le monde IT se rapproche doucement de
l’hyper-automatisation.
L’hyper-automatisation revient à automatiser l’automatisation. Cela requiert de
faire appel à des algorithmes d’apprentissages automatiques supervisés et non
supervisés, qui relèvent tous deux du domaine de l’intelligence artificielle (par
opposition au domaine des structures conditionnelles imbriquées, alias les “si
alors, si alors…”), et qui vont créer par eux-mêmes les modèles d’automatisation.
On peut ainsi apprendre à l’algorithme à détecter une attaque ou des activités
suspectes (par analyse de journaux, par exemple) et à prendre des décisions de
contre-mesures et de remédiation.
Il peut également s’agir de déployer une nouvelle règle de détection dans les
SIEM de toutes les filiales de l’entreprise pour capitaliser sur la première détec-
tion, ou d’exécuter un playbook qui automatise la correction (mise à jour en
provenance de l’éditeur) ou l’isolation (“mise en bastion”) en tenant compte d’un
niveau maximal de risque de régression fonctionnelle accepté par le responsable
del’infrastructurecible.Lemoteurd’intelligenceartificiellen’apasde“croyance”,
il analyse les choses dans leur ensemble avec un taux d’erreurs bien inférieur à
l’être humain et peut traiter des quantités phénoménales de données.
En tirant parti de l’apprentissage supervisé, l’algorithme “observe” des analystes
chevronnés réalisant des activités de type analyses d’événements, analyses et
détections de Zero-Day, “reverse engineering” : ainsi, on duplique la compétence
et enrichit le modèle d’intelligence artificielle.
Un avantage lorsqu’on sait que le déséquilibre entre besoins en cybersécurité
(à mettre en rapport avec le nombre d’attaques) et personnels disponibles sur le
marché ne cesse de s’accroître.
SÉBASTIEN TABARLY | Directeur technique cybersécurité, Capgemini
BENOÎT GRUNEMWALD
Directeur associé, ESET
_Cyberun#27
Si, pour les défenseurs, l’automa-
tisation de la remédiation de
chaque étape de la killchain est
un objectif, il en est de même
côté attaquants dans un but
offensif. Les opportunités et
outils sont légion. Qu’il s’agisse de back office,
dans l’optique de préparer ses infrastructures
(C2) et de les protéger, de rechercher des cibles,
de déposer des noms de domaines ou de créer
des certificats, des outils sur étagère ou maison
sont disponibles. La création de logiciels malveil-
lants n’échappe(ra) pas à l’automatisation. Arrêté
dans sa propagation, le malware next-gen
apprend de ses erreurs pour muter et devenir
plus furtif. Pour le front office, les outils pro-
gressent également. ChatGPT détonne et l’avenir
nous dira si l’on passe de proof of concept à un
usage réel. En attendant, pour créer des mes-
sages de hameçonnage ou répondre aux
demandes des victimes, quoi de mieux qu’un
chatbot ou une IA qui se charge des tâches
récurrentes et rébarbatives ?
La nouvelle phase de transformation numérique, qui émerge et
induit la généralisation de la cybersécurité, ne pourra pas adve-
nir par une mobilisation massive du facteur humain, faute de
combattants, mais plutôt par l’attribution de nouveaux outils
plus évolués. Dans tous les métiers de la sécurité, les opérateurs
peuvent gérer un plus large spectre de menaces par l’automati-
sation cyber. Car, s’il n’est pas de digitalisation sans cybersécu-
rité, ce qui la rend possible, c’est précisément l’automatisation
de la sécurité opérationnelle.
Quels sont ces axes d’automatisation qui visent à mettre l’humain
en capacité d’intervenir sur un plus large spectre ?
L’approche “effort Vs impact” dans le traitement des
incidents de masse
Petit rappel en matière de gestion d’incident : l’automatisation
vient soutenir l’action humaine, jamais l’inverse ! Les meilleures
automatisations sont en effet inutiles si elles sont pointées dans la
mauvaise direction. Automatiser la cybersécurité est d’abord sou-
haitable lorsque l’impact est faible au regard de l’effort humain :
en cas de pénurie d’analystes qualifiés, si la mobilisation d’un SOC
paraît disproportionnée et peu gratifiante pour l’humain, etc.
Prenons le cas de bateaux au milieu des océans, avec de
nombreux utilisateurs et accès wifi public, où les compor-
tements à bord peuvent générer des risques (mauvaise
hygiène cyber, usage de PC personnels, etc.). La sécurité
peut y être assurée à distance par un analyste aidé d’outils
automatisés capables de prendre des décisions simples,
comme bloquer les postes connectés à des sites web illé-
gaux ou envoyer des alertes mails aux utilisateurs en cas de
détection de téléchargement de fichiers suspects.
Recourir à l’automatisation sur des missions
de faible intensité, c’est permettre aux
analystes de gagner en confort et de
se consacrer à d’autres cas d’usage
où les enjeux sont bien plus élevés.
D’autres cas, plus rares mais à très
fort impact, sont également mieux
résolus par une automatisation,
laquelle ramène concrètement l’humain à une réactivité et une
sérénité suffisantes et amplifie ses capacités de vérification et
d’évaluation pour pouvoir prendre la meilleure décision.
En effet, une erreur d’appréciation peut avoir d’énormes consé-
quences pour l’entreprise. C’est prendre le risque qu’une infection
virale apparemment anodine soit en réalité une attaque par
ransomware qui peut atteindre le cœur du système en 15 minutes
et paralyser des organisations entières et des milliers d’utilisateurs,
parfois jusqu’aux moyens de production.
L’assistance en phase de collecte et d’investigation :
la clé de l’hyper-réactivité
L’analyste qui recourt à une assistance automatisée en phase
d’investigation réunit l’information plus rapidement. Il “optimise”
ces 15 minutes pour décider s’il doit prendre une décision globale,
à l’échelle de toute son organisation, sur plusieurs pays, ou en
isolant une plaque géographique, par exemple.
En mode passif, l’analyste lance des playbooks d’enrichissement,
qui sont la traduction dans le moteur d’automatisation d’enchaî-
nements de tâches. En un clic, il extrait des artefacts techniques
et interroge plusieurs dizaines de services tiers, soit
internes en mode protégé, soit externes en sous-
cription, pour en évaluer la cohérence et qualifier
l’incident. Cet usage systématique et à large
échelle des playbooks donne accès à toute l’in-
formation pertinente disponible, sur un seul
écran plutôt que sur plusieurs consoles. L’analyste
gagne du temps et peut se concentrer sur sa prise
de décision.
En mode actif aussi, l’investigation est automatisable.
Si l’apport de contexte est insuffisant pour se forger
une intime conviction, l’analyste peut
déclencher une phase d’interrogation
directe des systèmes de détection et
réponse. Sa plateforme lui propose alors
des requêtes que l’automate va distri-
buer et orchestrer sur l’ensemble des
points de contrôle (postes de travail,
Des attaques de plus
en plus automatisées
équipements réseau, filtres applicatifs, contrôles
d’accès et de privilèges, etc.). Pour agir vite, l’ana-
lyste a besoin d’autonomie dans la mise en œuvre.
Il doit être capable d’exécuter un mécanisme
automatique de remédiation à distance. Une forte
collaboration en amont s’impose avec l’ensemble
des parties prenantes, des responsables métiers
aux équipes infrastructures, lesquelles auront
conçu les procédures automatisables nécessaires
à l’analyste lorsqu’il actionnera sa prise de respon-
sabilité. De même, en matière de gouvernance,
l’automatisation par anticipation permet de
disposer des accès et d’obtenir à l’instant t les
autorisations pour exécuter automatiquement les
plans d’action : envoi de mails, ouverture de ticket,
sollicitation ou déclenchement d’astreinte, actions
techniques, etc.
Enfin, pour activer l’ensemble de la sphère sécu-
rité, y compris a posteriori, la phase d’exécution
de la remédiation s’accompagne impérativement
de traçabilité, de journalisation, elles aussi auto-
matisables pour l’historisation et le suivi. L’auto-
matisation déshumanisée est une illusion. Avec
une automatisation maîtrisée, les décisions et
actions automatisées viennent en amplification
des moyens de perception, d’analyse et d’inter-
vention des équipes. À tout moment, l’humain est
présent dans la prise de décision, et les équipes
disposent de renforts clés tout au long de la
chaîne. En cyber plus qu’ailleurs, c’est par la
collaboration étroite entre humains et machines
que les meilleurs résultats s’obtiennent.

3. _Cyberun#27
Réussir son automatisation implique d’embarquer les équipes, d’évaluer
les risques, de rationaliser ses outils et d’adapter son écosystème
de processus internes et de formation.
SÉCURITÉ OPÉRATIONNELLE, DÉTECTION
ET RÉPONSE À INCIDENT
L’ E N Q U Ê T E
Nous avons un triple
besoin : traiter une grande
quantité d’informations,
prendre une décision et le
faire dans un laps de
temps le plus court pos-
sible. Une réponse à cela : l’automatisa-
tion. Derrière ce terme, nous retrouvons
des scénarios de réponse préprogram-
més, mais également les promesses de
l’IA salvatrice.
Rappelez-vous, les outils SIEM propo-
saient déjà il y a 15 ans des capacités de
remédiation, en déclenchant un script (par
exemple le shutdown d’un port réseau)
suite à un scénario de corrélation. Le SOAR
et le XDR poussent ces capacités à leur
maximum et offrent des scénarios d’une
richesse incomparable et des mécanismes
d’aide à la décision, voire de décision
automatique, très efficaces. Mais est-ce
que cette automatisation résout réelle-
ment notre problème ? Pas vraiment car,
pour être efficaces, ces scénarios de “play-
book” ou les modèles d’IA doivent être
configurés spécifiquement, en fonction
d’une menace et d’un contexte. Pour cela,
des experts sont indispensables. Oui, pré-
cisément ceux dont on manque…
Ajoutez à cela deux critères d’arbitrage : le
coût de traitement d’un événement et l’ef-
ficacité de la remédiation. À raison de plu-
sieurs milliers d’événements par jour, le
premier critère devient vite élevé rien
qu’en capacités de stockage. Pour le
second, il dépend en grande partie de la
compétence de l’exploitant et peut aller
jusqu’à remettre en cause l’économie
d’échelle promise via du MDR ou du MSSP.
En effet, la réponse, impliquant souvent
des actions sur les équipements en pro-
duction, est très délicate à déléguer. On
donne la main à un tiers sur son SI, et
puisque certaines décisions ont un impact
de disponibilité parfois très fort (couper un
site, couper un accès mail, etc.), une vali-
dation par le métier est nécessaire avant
chaque action. Très peu d’entreprises ont
la maturité pour exécuter ces scénarios, et
le coût de mise en œuvre est élevé. Les
partisans de la détection massive ne
doivent donc pas oublier, ni faire oublier
ces questions de coûts indirects.
En matière d’efficience, il n’y a pas de
comparaison possible entre la détection
et la protection. Avec des outils de protec-
tion efficaces, plus besoin de réponse, de
traiter les événements, ou encore d’inter-
vention. L’attaque est purement bloquée,
mise en échec, sans action d’un tiers.
Le challenge étant alors de concevoir des
protections avec le moins de faux positifs
possible, et évidemment sans faux néga-
tifs. Cela implique des outils à jour en per-
manence face aux menaces existantes. En
déléguant cette tâche aux R&D des édi-
teurs, il est possible d’atteindre un niveau
de mutualisation efficace, tout en gardant
la main sur son SI. Mais, si l’utopie de
transformer la détection en protection par
le biais de l’automatisation ne peut exister,
celle de la protection parfaite ne doit pas
exister non plus. Comme toujours en
cybersécurité, on se doit d’utiliser toutes
les armes à disposition de la défense :
mettre en œuvre des protections efficaces
pour traiter 80 % des menaces et disposer
d’outils de détection performants pour les
20 % restants. Ainsi, on peut réduire le
volume d’événements, la charge et la
complexité de la mise en œuvre. On ne
soulignera jamais assez l’importance de
l’automatisation dans la transmission des
informations relatives aux menaces,
comme les IoA ou IoC, afin de nourrir en
temps réel les outils de protection et les
rendre encore plus efficaces.
Le sujet n’est donc pas d’opposer détec-
tion et protection, mais de mettre en
œuvre un cycle d’amélioration continu
“Détection-Automatisation-Protection”.
Et surtout d’accepter de mettre ces
ressources en commun pour tout l’éco-
système des défenseurs cyber.
SÉBASTIEN VIOU | Directeur cybersécurité produits, Stormshield
_04 / _05
Stop aux
fantasmes !
L’automatisation en
sécurité opérationnelle est
une réalité indéniable.
Mais elle est trop souvent
perçue comme la réponse
magique face à l’avancée
des cyberattaquants. Face
à des attaques de plus en
plus rapides et sophistiquées, les
entreprises ont des attentes de plus en
plus fortes, notamment sur le temps de
réaction (identification et réponse à
incident) et la pertinence des alertes
PIERRE DE CHAMPSAVIN
Head of Product Marketing, Advens
Automatiser sa réponse
à incident : une question d’outils
et de planification
Les organisations qui sont la cible d’une cyberat-
taque jouent un contre-la-montre. Plus le temps
passe, plus les dégâts potentiels peuvent être
importants, qu’il s’agisse d’une fuite ou d’une des-
truction de données, ou bien de la perturbation
d’un service métier. C’est pourquoi il est essentiel
de stopper le chronomètre le plus rapidement
possible. D’autant plus qu’avec la fréquence et la multiplicité des
menaces qui ne cessent de progresser, être en mesure de
s’appuyer sur une réponse à incident performante s’avère crucial.
Pour cela, l’automatisation semble tout indiquée. Subsiste toute-
fois la question de sa mise en œuvre : comment faire ?
Impliquer les équipes, évaluer les risques liés
à l’automatisation
La réponse à incident ne repose pas dans les mains d’une seule
et même équipe. En effet, la phase d’alerting d’un incident est
habituellement prise en charge par les équipes de sécurité infor-
matique et la phase de remédiation est dévolue aux équipes Ops.
Avec le soutien du top management, le plan d’automatisation doit
être porté par l’ensemble de l’organisation. Pour certaines entre-
prises, l’automatisation enlève une part de contrôle humain et
exposerait ainsi l’entreprise à un risque systémique. Pour dépasser
cet a priori, il est bien évidemment essentiel d’adapter ses plans
d’automatisation aux risques encourus. Le secteur bancaire en
est un bon exemple : les autorisations de paiement sans contact
sont automatisées et ne nécessitent pas d’intervention humaine
en dessous d’un certain montant. Au-dessus, elles nécessitent
bien évidemment la saisie d’un code PIN. Le tout étant de déter-
miner où placer le curseur.
Rationaliser les outils, adapter son écosystème
Plus concrètement, il faut d’abord commencer par simplifier et
homogénéiser les outils. En pratique, les entreprises font souvent
appel à des outils différents : un outil qui s’occupe de l’alerting,
un autre pour la remédiation, un troisième pour monitorer, voire
un quatrième qui s’occupe de la détection post-incident. Il est
alors compliqué – voire impossible – d’automatiser autant d’outils
car, souvent, ils ne s’appuient pas sur le même format de données
ou n’ont pas les mêmes façons de se connecter entre eux pour
partager les données.
Les entreprises doivent ensuite adapter leur écosystème pour
faciliter l’automatisation. Cela implique un travail sur les processus
internes, mais également sur la formation des équipes aux outils
utilisés. Limiter les outils réduit les processes à mettre en place et
les personnes à former sur des outils disparates. De plus, ratio-
naliser les outils facilite également la communication entre les
équipes, ainsi que le partage de données, des éléments essentiels
pour réussir l’automatisation.
DAMIEN BÉNAZET | Senior Director, Technical Account Management, Tanium
MICKAËL BEAUMONT
Product Manager, Advens
(limitation des faux positifs). En réponse,
certains éditeurs ont tendance à propo-
ser… des fonctionnalités miracles. Qui ont
forcément du mal à tenir leurs promesses.
Ces fonctionnalités un peu survendues
servent surtout à outiller les analystes
pour trier et qualifier plus facilement
l’alerte, mais moins souvent pour répondre
à l’incident.
Les trois limites de l’automatisation
Détecter, qualifier et identifier sont des
actions automatisables en grande partie.
Mais pour accomplir des actions de
remédiation, les solutions techniques des
clients doivent être orchestrables, ce qui
est facilité par la présence d’une API pour
administrer la technologie ciblée. Il est
aussi essentiel d’assurer la scalabilité de la
solution d’orchestration, afin de savoir
gérer un grand nombre d’automatisations.
Une solution on-premise, uniquement
gérable via une interface graphique, est
beaucoup plus compliquée à orchestrer
à distance. Pour automatiser les prises de
décision, il faut du contexte, ainsi que des
schémas et des modèles répétables et
contrôlés. Mais il est quasi impossible
d’avoir des référentiels de contexte
exhaustifs et à jour ! Les informations sont
souvent éparpillées et incomplètes, voire
uniquement dans la tête des sachants de
l’organisation à protéger.
Définir des cas de réactions automatiques
sur des périmètres ciblés et validés par le
client nécessite souvent des approbations,
impliquant des temps trop longs –
certaines obligent l’intervention de
plusieurs personnes : le contact principal
n’a pas le mandat, un tiers doit valider une
information avant la prise de décision, etc.
Une approche processus
et “automation by design”
La gestion d’un incident de sécurité est
un processus qui se découpe en étapes,
chacune devant être optimisée.
Les données de contexte et la Cyber Threat
Intelligence (CTI) doivent être intégrées le
plus en amont possible dans le processus
de gestion de l’incident (approche
data-centric) pour gagner du temps dans
l’analyse et limiter le nombre de traite-
ments d’alertes. Pour optimiser un process,
il faut aussi faire la chasse aux “gestes
inutiles”. C’est le principe de l’automation
by design : optimiser les workflows et
automatiser les actions triviales, répétitives
ou coûteuses des analystes.
Ainsi, en industrialisant la CTI et la revue
des plans de surveillance, il nous est
possible de faire bénéficier à l’ensemble
des organisations d’une base de connais-
sances mutualisées.
Quand on pense automatisation de la
cybersécurité opérationnelle, il faut
intégrer l’intégralité de la chaîne de
traitement, de l’enrichissement de la
donnée collectée aux gestes de
remédiation.
Des attaques toujours plus agressives
et en constante augmentation exigent
de l’automatisation. Mais ce n’est pas une
solution miracle ! La détection et la gestion
de l’incident peuvent être automatisées,
mais les actions de remédiation doivent
être guidées par l’humain. Et le contexte
de la donnée, l’intelligence collective
et l’excellence opérationnelle sont
indispensables pour y parvenir.

4. _Cyberun#27 _06 / _07
CHRISTINE GRASSI | Cloud Security Expert Director, Devoteam
Avec l’usage du cloud et le développement des
philosophies DevOps et Agile, le monde de l’IT
vit à nouveau une profonde révolution. Pour
continuer à jouer son rôle de façon pertinente,
la sécurité se doit elle aussi de réaliser une nou-
velle transformation, à travers l’intégration de
deux évolutions intrinsèquement liées : l’adaptation de son
modèle opérationnel et l’augmentation de la part d’automati-
sation de ses pratiques. L’automatisation de la sécurité cloud
peut être mise en œuvre au moins à cinq niveaux :
Shift-left – la sécurité en amont dans l’infra :
En s’appuyant sur la puissance de l’Infrastructure as Code (IaC) il
est possible d’automatiser le déploiement à l’échelle d’environ-
nements cloud qui intègrent de façon native les configurations
standards de sécurité, et ce dès les premières étapes de leur cycle
de développement. Ainsi, une entreprise du secteur pharmaceu-
tique a construit et mis à disposition de l’ensemble des équipes
IT dans le monde des modules d’IaC permettant de créer une
Landing Zone de façon rapide et autonome tout en étant sûre
d’intégrer par défaut toutes les bonnes pratiques d’architecture
en termes de performance, de FinOps et de sécurité.
Cloud Infrastructure Entitlement Management
(CIEM) – automatisation de la gestion des droits :
Labellisé par le Gartner en 2020, le CIEM vise à automatiser le
processus de gestion IAM des environnements cloud, en se
basant sur des dispositifs de Machine Learning et d’analyses avan-
cées. Il permet ainsi de rationaliser et simplifier le déploiement
d’une logique d’accès à “moindres privilèges”, et ce pour des
périodes étendues comme très limitées. Il y a fort à parier que les
solutions de ce type vont très vite trouver leur place dans les
organisations qui gèrent désormais des environnements cloud
à la structure de plus en plus étendue et complexe (logiques
multicloud, multi-entités, etc.).
Policy as Code (PaC)/Security as Code – la sécurité
dans le code :
Dans la continuité de l’IaC, la PaC permet d’utiliser du code, c’est-
à-dire un langage directement interprétable par les applications
(ex. : Python ou YAML) pour documenter des règles ou contrôles
de sécurité, puis automatiser leur mise en œuvre via un moteur
de politiques. Ce dispositif a ainsi permis à une entreprise du sec-
teur des transports de déclencher de façon automatisée des rou-
tines de vérification de la conformité sécurité d’un composant
avant tout déploiement en préproduction.
Posture Management – les contrôles automatisés :
Il existe désormais toute une gamme de services cloud et produits
tiers de type CSPM, CNAPP, CWPP (etc.) qui permettent de vérifier
de façon automatisée le niveau de conformité des plateformes
cloud et de leur contenu (services, containers, packages applica-
tifs, etc.) aux règles internes, bonnes pratiques et exigences régle-
mentaires de sécurité. Ces vérifications peuvent se faire aussi bien
à n’importe quelle étape du cycle de vie de développement que
juste en amont d’une exécution dans un environnement de
production.
Cet outil automatisé de contrôle a notamment permis à Bouygues
d’accompagner l’autonomisation croissante de ses équipes
DevOps dans le cadre de son programme MoveToCloud, tout en
assurant la conformité des infrastructures et déploiements aux
bonnes pratiques de sécurité.
Remédiation automatisée – les corrections
en temps réel :
L’objectif est de corriger de façon automatisée une anomalie liée
à une problématique de sécurité afin que cette anomalie ne se
reproduise plus. Il s’agit donc de traiter la cause en profondeur,
et pas seulement l’incident. Ces mécanismes de correction sont
à manipuler avec attention. Il est important d’avoir au préalable
une bonne compréhension du contexte organisationnel dans
lequel ils s’inscrivent, de communiquer de façon intensive avant
même leur mise en œuvre (et de continuer juste après !) et de
veiller à ce que ces mécanismes n’engendrent pas eux-mêmes
de nouveaux risques. Mais utilisés à bon escient et de façon
proportionnée, ils permettent notamment de limiter les cas de
négligence ou de malveillance, ou de compenser a posteriori les
limitations de paramétrage sécurité par défaut de certains
services ou applications. Ainsi, une entreprise du secteur bancaire
Le cloud et le DevOps révolutionnent l’automatisation de la sécurité :
nouvelles compétences, nouvelles pratiques… et nouveaux risques.
UTILISER LES OUTILS DU CLOUD
L’ E N Q U Ê T E
Schneider Electric a entrepris une modernisa-
tion de ses systèmes “legacy” existants en se
basant sur Kubernetes pour développer des
clusters de microservices cloud natifs. Comme
beaucoup d’organisations largement établies,
Schneider Electric a connu 25 ans d’évolution
technique, créant au fil du temps des milliers
de services et d’applications sur Windows
Server ou Red Hat. Certaines applications clés ont été migrées
sur le cloud en tant que services, tandis que d’autres ont été
totalement décommissionnées, puis reconstruites sous une
architecture microservice.
Kubernetes fonctionnait déjà sur certains centres d’excellence,
mais sans cohérence véritable. Plusieurs équipes de développe-
ment client avaient besoin d’accéder à des clusters, mais
comme aucun contrôle n’était opéré, cela impliquait la suspension
de l’usage de Docker. Le besoin d’une plateforme unifiée basée
sur des règles a rapidement émergé. Après un premier PoC,
Schneider Electric s’est appuyé sur les solutions de Rancher
Labs et d’Aqua Security pour le contrôle d’accès, la gestion des
identités et les mesures de performance globales non incluses
dans Kubernetes. Aujourd’hui, les développeurs
de Schneider Electric n’ont ainsi plus à se soucier de la sécurité,
de l’infrastructure sous-jacente ou des processus opérationnels.
Dotés de pipelines et de référentiels, ils exécutent leur charge
de travail de manière transparente en bénéficiant de contrôles
de sécurité poussés et pleinement intégrés. Schneider a ainsi
réduit les temps de déploiement et de gestion grâce à l’utilisation
d’une plateforme PaaS globale, tout en renforçant sa défense
avec l’automatisation des règles de sécurité et de la remédiation
via Aqua.
Du développement au déploiement, l’une des caractéristiques
majeures de l’utilisation des containers est la vitesse. Le cycle de
développement est non seulement plus rapide, mais aussi divisé
en plusieurs composants de petite taille constamment mis
à jour. Lors de l’exécution, ces mises à jour fréquentes et les
charges de travail parfois éphémères rendent ainsi difficile le
verrouillage de l’ensemble de l’environnement. Si l’automatisation
reste la norme dans DevOps, les outils et méthodes de sécurité
traditionnels n’ont pas été conçus pour les paramètres CI/CD
et sont généralement mal adaptés pour traiter les éléments de
sécurité des containers. En d’autres termes, il n’est pas possible
de suivre les mises à jour des images de containers, de fournir
des alertes fiables et de détecter les anomalies avec les outils
traditionnels. La recherche de vulnérabilités pendant le
développement, l’application de politiques de sécurité, mais
aussi le blocage des comportements suspects en production
doivent ainsi être automatisés.
a mis en place des règles de remédiation automatisée pour corriger
des cas spécifiques où le niveau de risque de non-conformité est
jugé critique, la chaîne de résolution simple ou le niveau d’impact
sur les utilisateurs relativement faible.
Des bénéfices décuplés
Par la standardisation induite, l’automatisation permet de réduire
significativement le taux de mauvaises configurations, qu’elles
soient dues à des erreurs humaines ou à une intention malveil-
lante – et ce jusqu’à 70 % selon l’étude de Snyk.io (State of Cloud
Security). L’amélioration de la productivité des équipes sécurité
permet ainsi de réorienter leur temps vers des tâches à plus forte
valeur ajoutée (ce qui, par effet de bord positif, rend leurs activités
beaucoup plus intéressantes et motivantes).
Simplifier les processus de correction des non-conformités ou
risques diminue considérablement le délai moyen de retour à la
normale. On évite également les différences d’interprétation ou
de mise en œuvre d’une règle de sécurité. Enfin, l’automatisation
permet à la sécurité de contribuer à l’amélioration générale de la
chaîne de valeur IT en s’inscrivant dans la logique de fiabilisation
des mises en production et de réduction de leur durée.
La mise en œuvre de toutes ces solutions automatisées nécessite
à la fois une évolution des technologies support et une redistri-
bution des rôles et responsabilités sécurité entre les différentes
équipes. Un des prérequis est d’enclencher avec le département
RH un programme de mise à jour des parcours de formation des
équipes de sécurité, pour qu’un plus grand nombre de ces experts
se familiarise à la programmation informatique, au déploiement
des services managés de sécurité des fournisseurs cloud, mais
aussi au quotidien des équipes DevOps, MLOps, architecte cloud,
etc. Un travail de fond aussi bien technique qu’organisationnel,
mais le jeu en vaut largement la chandelle !
Schneider Electric automatise la sécurité des containers
ALI MOKHTARI | Solution Architect, Aqua Security
– 1 –
Gestion des vulnérabilités
pendant le développement
Avec l’analyse de la sécurité des images de containers, dans le cadre du processus CI/CD,
les images sont autorisées (ou interdites) selon des règles et une politique clairement définie.
– 2 –
Définition et mise à jour
automatisée de politiques de sécurité
Les containers peuvent présenter des comportements différents (utilisation des ressources,
mise en réseau, accès aux fichiers) en fonction du contexte dans lequel ils opèrent.
Or les développeurs n’ont ni les compétences, ni le temps nécessaire pour définir manuellement
les paramètres de sécurité lorsque les images sont constamment mises à jour.
– 3 –
Blocage automatisé
des activités suspectes
Les déploiements de containers présentent une surface d’attaque plus grande par rapport
aux déploiements traditionnels, due à la quantité importante de code tiers, au nombre d’entités
à suivre et à la vitesse à laquelle les containers peuvent apparaître et disparaître.
Seul le profilage automatisé du comportement des containers permet de s’affranchir des limites
des outils de détection traditionnels (le flot d’alertes rendant impossible d’agir en temps opportun,
voire attaques déjà finies avant même que l’entreprise ait eu le temps de réagir).
Les 3 étapes clés

5. ADELINE VILLETTE | Cloud Security Officer, Decathlon
Tout informaticien pense que l’automatisation
se résume à déployer des outils qui remplace-
ront nos tâches répétitives. Ce n’est pas faux,
comme dirait un grand philosophe médiéval,
mais cela ne suffit pas pour réussir…
L’AppSec est la rencontre entre le monde de la
cybersécurité et celui du développement. Les développeurs
possèdent leur boîte à outils (dépôt de sources, chaînes d’inté-
gration continue, voire de déploiement continu, tests TDD ou
BDD, etc.) qui intègre rarement des outils de sécurité : SAST,
DAST, IAST ou autres RASP, WAF... Derrière chaque terme
marketing, se trouve un concept technologique pertinent qui
répond à un besoin précis. Mais les solutions miracles n’existent
pas, seules les solutions utiles sont à choisir. Intégrer tel ou tel
outil de sécurité sans initier les développeurs aux fondamentaux
de la cybersécurité amènera à un rejet par manque de compré-
hension des enjeux. Il faut donner du sens par les risques et non
comme une contrainte supplémentaire.
Le Groupe IRCEM a connu cet échec il y a quelques années. Afin
d’enrichir la chaîne CI/CD, SonarQube a été testé dans le cadre
d’un nouveau projet applicatif. Cette solution de qualité de code
a montré son intérêt pour ses partisans, mais n’a globalement pas
été adoptée. Certains experts avaient jugé qu’une évangélisation
n’était pas nécessaire. En outre, la solution a été déployée pen-
dant le projet applicatif, et non à son commencement.
Depuis, le Groupe IRCEM a établi une roadmap sur
2022-2023 pour le déploiement d’une culture AppSec entre
formations, outillages, bug bounty et règles d’urbanisation.
La modernisation du SI par l’introduction d’une stack techno-
logique récente est une opportunité, car elle crée une
dynamique du changement sur laquelle il est plus facile
de s’appuyer pour introduire de nouvelles notions.
Cette roadmap s’appuie sur des bases (tests d’intrusion récur-
rents dont les résultats commencent à être satisfaisants,
de précédentes sensibilisations à l’OWASP, un processus
de patch management devenant mature, etc.) et des souhaits
d’évoluer.
Il fallait alors orchestrer ces envies selon les priorités et les
moyens. La réflexion a débuté par le bug bounty pour aller plus
loin dans le contrôle du niveau de sécurité. Ce programme
implique aussi les développeurs via un programme de formation
: une session d’une journée pour les fondamentaux pour tous
les développeurs et une session de plusieurs jours pour les
notions avancées pour les développeurs éligibles à devenir les
“security champions”. Ces sessions de formation ont été des
espaces d’échanges entre cybersécurité et développement pour
introduire les outils aux acronymes tels que SAST, DAST ou WAF.
Une fois le prérequis de la formation assimilé, les chaînes CI/CD
sont enrichies par des outils DAST et de qualité de code sur
certains pipelines pour appréhender ces solutions avant une
généralisation. Nous réfléchissons aux alternatives du DAST,
mais aussi à des compléments autour du monde des contenairs
et de la gestion des dépendances applicatives.
Qui dit projet dit des femmes et des hommes. Le sujet de l’App-
Sec est sponsorisé par le RSSI et la direction informatique, il est
co-piloté par les parties prenantes de la démarche : urbaniste,
managers en charge des développement et RSSI. Cette organi-
sation permet une appréhension partagée du projet et une
co-construction des objectifs sans que la cybersécurité vienne
imposer une vision sécuritaire sur la situation originelle.
Les premiers retours sont positifs et il reste encore du chemin à
parcourir. Le Groupe IRCEM est dans une phase d’adoption de
la démarche sans rejet et la généralisation en 2023 sera le vrai
test quant à l’efficacité de l’automatisation en AppSec. Peu de
démarches AppSec sont des succès au départ car la recette
idéale ne semble pas encore trouvée : il est nécessaire de per-
sévérer pour convaincre du bien-fondé de la démarche sans
contraindre, ni culpabiliser les développeurs.
L’automatisation est un moyen de réussir dans le déploiement
d’une démarche AppSec, pas un objectif. L’automatisation faci-
lite d’ailleurs le Shift-left, il permet de passer d’une sécurité de
contrôle à une sécurité proactive en donnant les connaissances
et les outils directement aux développeurs.
Depuis plus de deux ans, nous gagnons ainsi un
temps précieux et allons même jusqu’à résoudre
automatiquement certaines alertes. Une fois
qu’un scénario a été identifié (comme, par
exemple, la compromission d’une instance),
les équipes impliquées commencent par sché-
matiser les étapes du traitement de l’incident à travers un
diagramme d’ordonnancement : source et destinataire de
l’alerte, analyse des logs, actions de remédiation, communica-
tion et, enfin, retour à l’état initial. Chaque étape est associée
à une liste d’outils à disposition pour la réaliser et à une équipe
qui en est responsable.
Les étapes sont ensuite documentées ; puis la chaîne complète
du traitement de l’incident est testée. Il est important que
chaque acteur impliqué maîtrise le processus et soit capable de
le jouer sans automatisation. Dans le cas de la compromission
d’une clé d’authentification, nos équipes doivent être, par
exemple, capables de procéder à sa désactivation.
Une fois le bon traitement validé avec les procédures manuelles
se pose la question de l’automatisation : est-elle envisageable
pour cette alerte ? Jusqu’où pouvons-nous aller ?
Dans les faits, la majorité des remédiations peuvent être auto-
matisées. Cette automatisation peut être déclenchée par une
personne une fois l’analyse de l’incident et des logs effectuée.
Ainsi, les actions de remédiation sont réalisées plus rapidement,
sans avoir besoin de lire des procédures parfois complexes – et
en oubliant peut-être certaines étapes importantes au
passage.
Mais, pour certaines alertes, nous pouvons également faire le
choix d’exécuter automatiquement la remédiation dès la détec-
tion. Prenons l’exemple d’une clé d’authentification AWS ou GCP
qui se retrouverait exposée sur un repository de code public. Ce
type d’alerte peut arriver plus souvent qu’on ne le pense et peut
avoir de graves conséquences en fonction des permissions qui
lui sont attribuées (vol de données, création/destruction de res-
sources). Dans ce cas de figure, la désactivation de cette clé sera
faite automatiquement (une clé exposée est considérée comme
compromise, même si non exploitée, et doit être obligatoire-
ment renouvelée). Ainsi, la clé compromise ne reste en ligne que
quelques secondes, donc le risque d’exploitation est fortement
réduit.
Bien entendu, cela n’empêche pas une mobilisation des équipes
concernées en cas d’alerte, même si son traitement est 100 %
automatisé. En effet, il est indispensable qu’une personne inter-
vienne pour vérifier la bonne désactivation de la clé et analyser
les logs de son usage pendant la période d’exposition.
Quel que soit le type d’alerte, toutes les étapes sont travaillées
avec l’ensemble des équipes concernées. Chaque personne
viendra apporter son expertise, et c’est même une opportunité
de faire monter en compétences nos équipes.
Le temps de mise en œuvre d’une telle automatisation varie en
fonction de la complexité de la réponse à incident et de l’outil-
lage à disposition.
La désactivation d’une clé d’authentification AWS ou GCP est
assez facile à automatiser (quelques lignes de code). Le déve-
loppement permettant l’isolation d’une instance compromise
prendra un peu plus de temps, car cela nécessite plus d’actions
(isolation de l’instance d’un point de vue réseau et cloud IAM et
prise de snapshot, par exemple).
Enfin, l’usage du serverless est d’une grande utilité pour créer
ce type d’automatismes et les exécuter facilement (AWS Lambda
ou GCP Cloud Functions). Lorsque les actions de remédiation
sont déclenchées automatiquement, nous consommons les
services de gestion des événements des Cloud Providers
(comme AWS EventBridge, par exemple). C’est cet usage com-
biné des services proposés par les Cloud Providers qui nous
permet d’atteindre une résolution inférieure à la minute dans le
cas de l’exposition d’une clé d’authentification, par exemple.
Deux ans après avoir automatisé la remédiation de notre
première alerte, ce processus a prouvé son bon fonctionnement
et son utilité chez Decathlon. Nous continuons donc à enrichir
notre catalogue pour être toujours plus réactifs lorsqu’un inci-
dent de sécurité se produit sur le cloud public.
BERTRAND MÉENS | DSI adjoint, Groupe IRCEM
_08 / _09
_Cyberun#27
Quand nous parlons d’AppSec (Sécurité applicative) ou de DevSecOps
(intégration de la cybersécurité dans la culture DevOps), nous pensons
aux notions de security by design, de Shift-left et d’automatisation.
IRCEM AUTOMATISE SA CHAÎNE
DE DÉVELOPPEMENT
R E T O U R S D ’ E X P É R I E N C E S
Le cloud (public) facilite l’automatisation des actions. Chez Decathlon,
nous avons donc choisi d’en tirer bénéfice dans la gestion de nos
incidents de sécurité.
DECATHLON : GESTION DES INCIDENTS
DE SÉCURITÉ CLOUD
R E T O U R S D ’ E X P É R I E N C E S

6. Comment collecter, consolider et diffuser les connaissances sur
les menaces à l’ensemble de la chaîne cyber malgré l’augmentation
des indicateurs et de la vitesse de réaction ?
AUTOMATISER LA THREAT INTELLIGENCE
La Cyber Threat Intelli-
gence (CTI) fait briller les
yeux des responsables
de SOC. En effet, la
promesse que la fine
connaissance des Tac-
tiques, techniques et
procédures (TTP), des
Modes opératoires d’at-
taque (MOA), permette
de détecter les “APT” est, il faut l’avouer,
très alléchante. Cependant, comment
faire face au volume croissant d’indica-
teurs de compromissions, de signatures
et de renseignements qu’apporte la CTI ?
L’automatisation est évidemment un des
leviers actionnables. Néanmoins, il est
important de commencer par une tâche
qui, elle, n’est pas automatisable, à savoir
la définition des menaces prioritaires
associées à votre organisation. Cette
étape primordiale nécessite une première
itération manuelle en collaboration avec
le métier, afin de définir les sujets priori-
taires, et permet, in fine, de diminuer
la quantité d’informations à traiter
ultérieurement.
Pour les équipes les plus matures, la mise
en place de cette démarche d’automatisa-
tion de la CTI se décline à l’ensemble du
cycle du processus de traitement. Tout
d’abord, pour la collecte d’informations :
des protocoles standardisés, comme le
TAXII, gagnent en popularité et permettent
d’obtenir du renseignement déjà structuré
au format STIX. Certains fournisseurs de
CTI s’appuient sur ce format naturellement,
d’autres non… Si vous ne faites pas partie
de ces chanceux, l’ingestion artisanale de
données non structurées, qui consiste à
extraire manuellement les entités et indi-
cateurs techniques dans des rapports
fichiers PDF, tweets ou blogposts, pour
convertir le tout dans un “graphe STIX”, est
encore malheureusement une tâche
récurrente chez de nombreux analystes.
Les outils d’automatisation se basent
aujourd’hui encore principalement sur des
expressions régulières : il va falloir encore
attendre les solutions efficaces basées sur
du langage naturel (Natural Language
Processing - NLP).
La production d’informations techniques
comme le suivi d’infrastructures malveil-
lantes via l’interrogation de services de
scan avec des heuristiques de suivi, la
récupération de binaires malveillants via
des règles YARA, les alertes des équipe-
ments de sécurité du SI (etc.) peuvent et
doivent être automatisées au vu de la
volumétrie et de la fréquence des mises à
jour des infrastructures d’attaque. Le
traitement de ces données, après norma-
lisation et enrichissement, doit mettre en
œuvre des mécanismes de vérification
afin de s’assurer de la pertinence des
informations, et ainsi éviter la hantise des
responsables de SOC, la remontée d’un
“faux positif” qui pourrait entraver l’activité
métier.
La phase d’analyse et de production de
renseignement est sans doute la plus
difficile à automatiser. L’automatisation
de certaines procédures comme
Automatiser la CTI : TAXII, STIX YARA à la rescousse
“Structured Threat Information
Expression” est un langage et modèle de
données pour exprimer les menaces dans
le cyberespace développé par le consor-
tium OASIS OPEN. La dernière version 2.1
publiée en juin 2021 se compose de trois
catégories d’objets :
_Domain Objects : pour décrire des
concepts (campagne d’attaque, inci-
dent,identité,groupe,indicateur,etc.)
_Cyber-observable Objects : pour
décrire des informations techniques
(adresse IP, adresse mail, fichier, flux
réseau, etc.)
_Relationship Objects : pour décrire
des relations entre ces objets.
Le STIX permet ainsi de documen-
ter sous la forme d’un graphe
orienté et labellisé les actions menées par
un attaquant. Il offre de plus un méca-
nisme d’extension qui permet d’ajouter
des attributs aux objets existants et de
créer de nouveaux objets. Le projet MITRE
ATTCK utilise par exemple ce mécanisme
pour décrire d’autres concepts, comme
les sources de données à utiliser pour la
détection de techniques d’attaques.
“Trusted Automated Exchange of
Intelligence Information” est un protocole
HTTP REST qui spécifie comment échanger
des données de CTI dans le format STIX.
Dans sa dernière version, le modèle de
partage “client-serveur” est documenté et
permet à un client de requêter les données
hébergées dans des catalogues de rensei-
gnements sur un serveur avec quelques
capacités de filtrage. Un second modèle
“publish-subscribe” pour partager du
renseignement dans une communauté est
évoqué dans les spécifications, mais n’est
pas encore défini.
“Yet Another Recursive/Ridicu-
lous Acronym” est un outil open source
créé en 2013 pour identifier et
classer les malwares à l’aide d’un
langage descriptif. Celui-ci est
basé sur de simples chaînes de
caractères, des représentations de
structures binaires et des condi-
tions logiques entre ces éléments,
et offre ainsi la possibilité de
spécifier des éléments marquants
d’un binaire sur disque ou en
mémoire. Une signature basique
d’un malware non obfusqué
consistera à simplement vérifier la
présence de quelques chaînes de carac-
tères relatives aux arguments du malware,
alors qu’une signature plus évoluée pourra
utiliser des modules supplémentaires
pour, par exemple, calculer l’entropie
d’une section d’un binaire.
_10 / _11
_Cyberun#27
YOHANN LEPAGE | Analyste CTI, EDF
R E T O U R S D ’ E X P É R I E N C E S
THOMAS BURNOUF | Manager SOC, EDF
Le SOC (Security Operation Center) du
Groupe EDF est chargé de la détection
d’actes malveillants sur le système
d’information de l’ensemble du groupe
EDF (EDF SA et ses filiales), 24 heures
sur 24, 7 jours sur 7. L’équipe est
composée d’une cinquantaine
d’experts internes au groupe EDF
et d’un ensemble de prestataires
en appui. Cette équipe
est majoritairement internalisée
depuis l’année dernière pour répondre
aux besoins et aux enjeux du G roupe
dans le domaine de la cybersécurité.
L’ensemble des acteurs du SOC se situe
en France, dans les villes de Nanterre,
Nancy, Lyon et Rennes.
Le SOC est en place depuis 2015, ses
missions ont évolué au fil des années
et de sa maturité. Aujourd’hui, le SOC
coordonne ses actions avec le CERT
(Computer Emergency Response
Team) du Groupe EDF, le VOC
(Vulnerability Operation Center)
et l’ensemble des acteurs cyber
opérationnels au sein du Groupe.
Le SOC se concentre sur la prévention
des risques cyber (via la sensibilisation
des utilisateurs), l’amélioration des
moyens de détection, l’analyse et la
qualification des alertes, et la réponse
aux incidents de sécurité informatique,
en coordination directe avec le CERT
Groupe. Par ailleurs, le SOC EDF est
qualifié PDIS (Prestataire de détection
d’incident de sécurité) depuis 2021.
l’identification de similarités pour la
conception d’heuristiques de suivi, la
détection d’anomalies associables à des
erreurs de SecOps peuvent cependant
représenter un gain de temps non négli-
geable aux analystes.
Par la suite, le renseignement produit en
interne ou collecté via des partenaires ou
fournisseurs peut être pleinement
exploité. Et pour cela, le SOAR (Security
Orchestration Automation and Response)
est un allié à étudier sérieusement. Face au
nombre croissant d’alertes et au manque
de ressources, le SOAR ne fait pas seule-
ment briller les yeux des responsables de
SOC, il permet également d’automatiser
en partie l’exploitation de la CTI.
Le SOAR peut tout d’abord vous aider à
vérifier la qualité de vos indicateurs en les
recherchant dans vos journaux, EDR, XDR,
etc. Cette recherche permettra d’écarter
les indicateurs trop verbeux car erronés,
pas assez discriminants ou expirés, et per-
mettra d’identifier de potentielles com-
promissions passées ou en cours. Une fois
cette recherche réalisée, le SOAR pourra
transférer les indicateurs qualifiés dans des
équipements de détection. Bien entendu,
traiter du SOAR dans son intégralité néces-
siterait bien plus que quelques lignes,
cependant, voici les éléments incontour-
nables à prendre en compte avant de vous
lancer dans une démarche d’automatisa-
tion de vos alertes cyber. Premièrement,
ne pas oublier que le SOAR n’est pas
magique : il faut un certain investissement
et une certaine maturité de traitement
avant de pouvoir automatiser ne serait-ce
que la contextualisation de ses alertes
avec sa CTI, avec le contexte de son entre-
prise, mais encore faut-il avoir une CMDB
(base de données de gestion de configu-
ration) à jour et correctement organisée.
Ensuite, il est impératif de prévoir le jour
où votre SOAR sera en panne et de vous
assurer que vos analystes soient toujours
en capacité de travailler en mode dégradé,
aussi bien en termes d’outillage que
de documentation des procédures de
traitement.
S’appuyer sur une Threat Intelligence
Platform (TIP) est également un bon
moyen de consolider votre connaissance
de la menace. Ces solutions proposent
d’ailleurs souvent des mécanismes simi-
laires au SOAR pour réaliser de l’enrichis-
sement ou des recherches dans votre
SIEM. Le choix de réaliser ces actions dans
votre SOAR ou votre TIP dépendra des
fonctionnalités offertes, et surtout de la
maîtrise de ces outils par vos analystes.
LesTIPaurontgénéralementuneintégration
plus poussée de certains concepts, comme
le TLP (Traffic Light Protocol) pour le
contrôle de la diffusion des informations,
et le PAP (Permissible Actions Protocol)
pour l’utilisation des informations, mais
seront plus limitées dans la mise en place
de workflows avancés. En complément du
stockage normalisé de vos indicateurs,
une TIP vous permettra aussi d’agréger
les traces des indicateurs que vous avez
pu observer sur votre SI. Enfin, une bonne
TIP vous offrira des fonctionnalités de
reporting pour diffuser aussi bien de
l’information technique, comme des
“sightings”, que de l’information consoli-
dée de niveau stratégique en dégageant,
par exemple, des tendances dans les
secteurs ou les ressources privilégiées par
les attaquants.
Au prix d’un investissement humain initial
important, la mise en place d’automatisa-
tions de workflows de traitement aug-
mentera la vélocité de vos analystes et leur
permettra de consacrer du temps à des
tâches à plus forte valeur ajoutée. Qui n’a
pas rêvé de temps libre pour ses analystes ?
L’automatisation ne permettra pas de
répondre à ce doux rêve mais, à défaut,
permettra de mieux consacrer ce temps si
précieux à la défense.
SOC EDF
1 2 3 4 5
Incident
Identification d'un fichier
suspect sur un serveur
web
Investigation
Analyse du fichier
suspect : un webshell
Création
d'indicateurs
Règle de détection YARA
Capitalisation
Création d'un rapport
dans la TIP
Diffusion
Mise à disposition dans une
collection TAXII du rapport avec
les indicateurs au format STIX

7. Les grognements de Cy
Pour la première fois, je vais pouvoir hiberner
tranquillement. Ma tanière est rangée nickel, tout est
calme, aucun souci à l’horizon.
Bref, je me fais C*#$%R ! À tel point que je papote depuis
ce matin avec BearGPT (y’a pas que les félins qui font de
l’IA). M’inspirant de posts sur LinkedIn, je lui demande
(en français) de rédiger une aventure de Cy.
La réponse est assez bluffante, mais je veux “plus rigolo”
et qu’un personnage soit ajouté. Je découvre que j’ai :
“un énorme téléphone portable (adapté à [mes] grosses
pattes d’ours)” et que ma “meilleure amie, une renarde
brillante et astucieuse [est] nommée Sasha”.
Heureusement, “ensemble, [nous avons] réussi à bloquer
les hackers et à sauver l’Alaska de la catastrophe
informatique”. Pour une fois que quelqu’un est satisfait
et me félicite ! Dommage que ce ne soit qu’une IA.
Finalement, ne devrait-on pas chercher à automatiser
les “chefs” plutôt que les “ouvriers” ?
Qui sommes-nous ?
Cyberun est un magazine totalement indépendant, édité par
financement participatif. Il fédère une large communauté d’acteurs
de la cybersécurité qui souhaitent partager leurs expertises
et leurs expériences. Pour favoriser l’échange de connaissances
et ne pas se contenter d’approximations, chaque numéro est dédié
à un thème unique.
Abonnez-vous gratuitement à Cyberun !
Recevez automatiquement le magazine en PDF
en vous inscrivant sur cyberun.net et découvrez
comment vous pouvez, vous aussi, participer
à cette aventure !
Contactez-nous !
Pour diffuser ce magazine lors d’un événement, rejoindre
la communauté, ou pour toute information complémentaire :
www.cyberun.net (lien “Rejoignez la communauté !”)
Cy-Bear, le gentil ours vivant en Alaska...
Imprimez-moi ! Ne me jetez pas, partagez-moi !
Le magazine Cyberun est un bimestriel
édité par Cyberun, association loi 1901.
Boîte 81, 206 quai de Valmy, 75010 Paris.
Directrice de publication :
Hélène Windish
Rédacteur en chef : Stéphane Darget
Création et maquette :
www.rodolpherrera.fr
Correctrice : Amandine Olivier
ISSN : 2677-5964. Toute reproduction,
traduction, reproduction intégrale ou
partielle est interdite, sans l’autorisation
écrite de Cyberun, sauf dans les cas
prévus par l’article L122-5 du Code
de la propriété intellectuelle. En tant
qu’abonné au magazine, vous êtes
autorisé à imprimer votre exemplaire.
Prix au numéro (imprimé et expédié) : 25 €
Les 10 conseils de nos experts
Une bonne maturité de ses équipes et un fort investissement
initial sont quasi systématiques pour réussir une
automatisation.
Ne négligez pas le travail collaboratif entre toutes les parties
prenantes, y compris les métiers, les opérateurs, et pas
simplement avec les différentes équipes de sécurité.
Une fois en place, veillez à ne pas “noyer” vos opérateurs
sous les alertes automatiques.
Ainsi, si la sécurité n’est pas prévue en amont dans une
approche Shift-left, l’automatisation aura pour conséquence
de multiplier les vecteurs d’attaque en production, et donc
les événements de sécurité à traiter.
Malgré les apparences, les IA ne sont pas magiques
et peuvent introduire des biais, souvent liés aux modèles
des données qui les ont entraînées.
Disposez systématiquement d’un Plan de continuité
d’activité en cas de perte des automates.
Automatiser la sécurité ne doit pas la mettre en péril :
attention, ces nouveaux développements utilisent souvent
des ressources très critiques.
En AppSec, l’automatisation est une clé de la réussite
pour l’adoption de la démarche par les développeurs.
Toutefois, l’outillage technique ne doit pas éclipser
le changement culturel à réaliser.
En environnement cloud, vérifiez que les composants
d’infrastructure as code (tels que Terraform, CloudFormation
ou encore ARM) n’intègrent pas de composants vulnérables,
voire secrets.
L’automatisation doit permettre de simplifier les traitements
et gagner en réactivité. Les promesses (marketing)
n’engagent que ceux qui les écoutent !