SlideShare une entreprise Scribd logo
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.
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.
_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.
_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
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
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
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 !

Contenu connexe

Similaire à cyberun #27

sécurité informatique notion de securité
sécurité informatique notion de securitésécurité informatique notion de securité
sécurité informatique notion de securité
ssuserc72852
 
Passer de la détection d’anomalies à la détection de menaces
Passer de la détection d’anomalies à la détection de menacesPasser de la détection d’anomalies à la détection de menaces
Passer de la détection d’anomalies à la détection de menaces
ITrust - Cybersecurity as a Service
 
anssi-guide-tpe_pme.pdf
anssi-guide-tpe_pme.pdfanssi-guide-tpe_pme.pdf
anssi-guide-tpe_pme.pdf
rodolphe gilbert-collet
 
Reveelium, solution innovante pour analyser les cyber menaces @ITrustBlog
Reveelium, solution innovante pour analyser les cyber menaces @ITrustBlogReveelium, solution innovante pour analyser les cyber menaces @ITrustBlog
Reveelium, solution innovante pour analyser les cyber menaces @ITrustBlog
ITrust - Cybersecurity as a Service
 
Le Machine Learning pour lutter contre les menaces en termes de Cybersécurité...
Le Machine Learning pour lutter contre les menaces en termes de Cybersécurité...Le Machine Learning pour lutter contre les menaces en termes de Cybersécurité...
Le Machine Learning pour lutter contre les menaces en termes de Cybersécurité...
Philippe Beraud
 
IBM Security Intelligence Juin-2016
IBM Security Intelligence Juin-2016IBM Security Intelligence Juin-2016
IBM Security Intelligence Juin-2016
Serge Richard
 
Dossier de presse - Assises de la Sécurité 2016
Dossier de presse - Assises de la Sécurité 2016Dossier de presse - Assises de la Sécurité 2016
Dossier de presse - Assises de la Sécurité 2016
Laetitia Berché
 
Livret Seamless Security exaprobe & Cisco
Livret Seamless Security exaprobe & CiscoLivret Seamless Security exaprobe & Cisco
Livret Seamless Security exaprobe & Cisco
Exaprobe
 
Baromètre BlackNoise 2022.pdf
Baromètre BlackNoise 2022.pdfBaromètre BlackNoise 2022.pdf
Baromètre BlackNoise 2022.pdf
ssuser384b72
 
Détecter et neutraliser efficacement les cybermenaces !
Détecter et neutraliser efficacement les cybermenaces !Détecter et neutraliser efficacement les cybermenaces !
Détecter et neutraliser efficacement les cybermenaces !
Kyos
 
Démystifier la gestion des vulnérabilités
Démystifier la gestion des vulnérabilitésDémystifier la gestion des vulnérabilités
Démystifier la gestion des vulnérabilités
NRC
 
Advanced persistent threat = émergence du simple vandalisme au cybercrimine...
Advanced persistent threat =  émergence du simple vandalisme au cybercrimine...Advanced persistent threat =  émergence du simple vandalisme au cybercrimine...
Advanced persistent threat = émergence du simple vandalisme au cybercrimine...
ITrust - Cybersecurity as a Service
 
La sécurité au service de l’innovation [#CloudAccelerate 13/06/2014 @ IBM CC ...
La sécurité au service de l’innovation [#CloudAccelerate 13/06/2014 @ IBM CC ...La sécurité au service de l’innovation [#CloudAccelerate 13/06/2014 @ IBM CC ...
La sécurité au service de l’innovation [#CloudAccelerate 13/06/2014 @ IBM CC ...
IBM France PME-ETI
 
L'antivirus ne fait pas partie des meubles
L'antivirus ne fait pas partie des meublesL'antivirus ne fait pas partie des meubles
L'antivirus ne fait pas partie des meubles
NRC
 
Sortir des sentiers battus: les TI et l’entreprise s’unissent pour innover
Sortir des sentiers battus: les TI et l’entreprise s’unissent pour innoverSortir des sentiers battus: les TI et l’entreprise s’unissent pour innover
Sortir des sentiers battus: les TI et l’entreprise s’unissent pour innover
PECB
 
Sécurité informatique : un marché dynamisé par le Big Data @ITrustBlog
Sécurité informatique : un marché dynamisé par le Big Data @ITrustBlogSécurité informatique : un marché dynamisé par le Big Data @ITrustBlog
Sécurité informatique : un marché dynamisé par le Big Data @ITrustBlog
ITrust - Cybersecurity as a Service
 
La sécurité endpoint : efficace, mais pas efficient
La sécurité endpoint : efficace, mais pas efficientLa sécurité endpoint : efficace, mais pas efficient
La sécurité endpoint : efficace, mais pas efficient
ITrust - Cybersecurity as a Service
 
Guide cgpme annsi bonnes pratiques
Guide cgpme annsi bonnes pratiquesGuide cgpme annsi bonnes pratiques
Guide cgpme annsi bonnes pratiques
Sophie Roy
 
Article (Version intégrale) - Les PME ne sont pas protégées contre la cybercr...
Article (Version intégrale) - Les PME ne sont pas protégées contre la cybercr...Article (Version intégrale) - Les PME ne sont pas protégées contre la cybercr...
Article (Version intégrale) - Les PME ne sont pas protégées contre la cybercr...
Crossing Skills
 
EXTRA-Présentation generale 180923.pptx
EXTRA-Présentation generale 180923.pptxEXTRA-Présentation generale 180923.pptx
EXTRA-Présentation generale 180923.pptx
Infopole1
 

Similaire à cyberun #27 (20)

sécurité informatique notion de securité
sécurité informatique notion de securitésécurité informatique notion de securité
sécurité informatique notion de securité
 
Passer de la détection d’anomalies à la détection de menaces
Passer de la détection d’anomalies à la détection de menacesPasser de la détection d’anomalies à la détection de menaces
Passer de la détection d’anomalies à la détection de menaces
 
anssi-guide-tpe_pme.pdf
anssi-guide-tpe_pme.pdfanssi-guide-tpe_pme.pdf
anssi-guide-tpe_pme.pdf
 
Reveelium, solution innovante pour analyser les cyber menaces @ITrustBlog
Reveelium, solution innovante pour analyser les cyber menaces @ITrustBlogReveelium, solution innovante pour analyser les cyber menaces @ITrustBlog
Reveelium, solution innovante pour analyser les cyber menaces @ITrustBlog
 
Le Machine Learning pour lutter contre les menaces en termes de Cybersécurité...
Le Machine Learning pour lutter contre les menaces en termes de Cybersécurité...Le Machine Learning pour lutter contre les menaces en termes de Cybersécurité...
Le Machine Learning pour lutter contre les menaces en termes de Cybersécurité...
 
IBM Security Intelligence Juin-2016
IBM Security Intelligence Juin-2016IBM Security Intelligence Juin-2016
IBM Security Intelligence Juin-2016
 
Dossier de presse - Assises de la Sécurité 2016
Dossier de presse - Assises de la Sécurité 2016Dossier de presse - Assises de la Sécurité 2016
Dossier de presse - Assises de la Sécurité 2016
 
Livret Seamless Security exaprobe & Cisco
Livret Seamless Security exaprobe & CiscoLivret Seamless Security exaprobe & Cisco
Livret Seamless Security exaprobe & Cisco
 
Baromètre BlackNoise 2022.pdf
Baromètre BlackNoise 2022.pdfBaromètre BlackNoise 2022.pdf
Baromètre BlackNoise 2022.pdf
 
Détecter et neutraliser efficacement les cybermenaces !
Détecter et neutraliser efficacement les cybermenaces !Détecter et neutraliser efficacement les cybermenaces !
Détecter et neutraliser efficacement les cybermenaces !
 
Démystifier la gestion des vulnérabilités
Démystifier la gestion des vulnérabilitésDémystifier la gestion des vulnérabilités
Démystifier la gestion des vulnérabilités
 
Advanced persistent threat = émergence du simple vandalisme au cybercrimine...
Advanced persistent threat =  émergence du simple vandalisme au cybercrimine...Advanced persistent threat =  émergence du simple vandalisme au cybercrimine...
Advanced persistent threat = émergence du simple vandalisme au cybercrimine...
 
La sécurité au service de l’innovation [#CloudAccelerate 13/06/2014 @ IBM CC ...
La sécurité au service de l’innovation [#CloudAccelerate 13/06/2014 @ IBM CC ...La sécurité au service de l’innovation [#CloudAccelerate 13/06/2014 @ IBM CC ...
La sécurité au service de l’innovation [#CloudAccelerate 13/06/2014 @ IBM CC ...
 
L'antivirus ne fait pas partie des meubles
L'antivirus ne fait pas partie des meublesL'antivirus ne fait pas partie des meubles
L'antivirus ne fait pas partie des meubles
 
Sortir des sentiers battus: les TI et l’entreprise s’unissent pour innover
Sortir des sentiers battus: les TI et l’entreprise s’unissent pour innoverSortir des sentiers battus: les TI et l’entreprise s’unissent pour innover
Sortir des sentiers battus: les TI et l’entreprise s’unissent pour innover
 
Sécurité informatique : un marché dynamisé par le Big Data @ITrustBlog
Sécurité informatique : un marché dynamisé par le Big Data @ITrustBlogSécurité informatique : un marché dynamisé par le Big Data @ITrustBlog
Sécurité informatique : un marché dynamisé par le Big Data @ITrustBlog
 
La sécurité endpoint : efficace, mais pas efficient
La sécurité endpoint : efficace, mais pas efficientLa sécurité endpoint : efficace, mais pas efficient
La sécurité endpoint : efficace, mais pas efficient
 
Guide cgpme annsi bonnes pratiques
Guide cgpme annsi bonnes pratiquesGuide cgpme annsi bonnes pratiques
Guide cgpme annsi bonnes pratiques
 
Article (Version intégrale) - Les PME ne sont pas protégées contre la cybercr...
Article (Version intégrale) - Les PME ne sont pas protégées contre la cybercr...Article (Version intégrale) - Les PME ne sont pas protégées contre la cybercr...
Article (Version intégrale) - Les PME ne sont pas protégées contre la cybercr...
 
EXTRA-Présentation generale 180923.pptx
EXTRA-Présentation generale 180923.pptxEXTRA-Présentation generale 180923.pptx
EXTRA-Présentation generale 180923.pptx
 

Plus de bertrandmeens

Cyberun #12
Cyberun #12Cyberun #12
Cyberun #12
bertrandmeens
 
Opensource et AppSec : amis ou ennemis ?
Opensource et AppSec : amis ou ennemis ?Opensource et AppSec : amis ou ennemis ?
Opensource et AppSec : amis ou ennemis ?
bertrandmeens
 
DevSecOps ou comment faire rimer cybersécurité et agilité
DevSecOps ou comment faire rimer cybersécurité et agilitéDevSecOps ou comment faire rimer cybersécurité et agilité
DevSecOps ou comment faire rimer cybersécurité et agilité
bertrandmeens
 
La privacy en 2018
La privacy en 2018La privacy en 2018
La privacy en 2018
bertrandmeens
 
Le Bug Bounty en 2017
Le Bug Bounty en 2017Le Bug Bounty en 2017
Le Bug Bounty en 2017
bertrandmeens
 
DevSecOps : de la théorie à la pratique
DevSecOps : de la théorie à la pratiqueDevSecOps : de la théorie à la pratique
DevSecOps : de la théorie à la pratique
bertrandmeens
 

Plus de bertrandmeens (6)

Cyberun #12
Cyberun #12Cyberun #12
Cyberun #12
 
Opensource et AppSec : amis ou ennemis ?
Opensource et AppSec : amis ou ennemis ?Opensource et AppSec : amis ou ennemis ?
Opensource et AppSec : amis ou ennemis ?
 
DevSecOps ou comment faire rimer cybersécurité et agilité
DevSecOps ou comment faire rimer cybersécurité et agilitéDevSecOps ou comment faire rimer cybersécurité et agilité
DevSecOps ou comment faire rimer cybersécurité et agilité
 
La privacy en 2018
La privacy en 2018La privacy en 2018
La privacy en 2018
 
Le Bug Bounty en 2017
Le Bug Bounty en 2017Le Bug Bounty en 2017
Le Bug Bounty en 2017
 
DevSecOps : de la théorie à la pratique
DevSecOps : de la théorie à la pratiqueDevSecOps : de la théorie à la pratique
DevSecOps : de la théorie à la pratique
 

Dernier

Alternative - Complément au Tramway et 3ème lien de la ville de Québec
Alternative - Complément  au Tramway et 3ème lien de la ville de Québec  Alternative - Complément  au Tramway et 3ème lien de la ville de Québec
Alternative - Complément au Tramway et 3ème lien de la ville de Québec
Daniel Bedard
 
COURS ANALYSE FINANCIERE-NOGLO Méthodes d’analyses financières.pdf
COURS ANALYSE FINANCIERE-NOGLO Méthodes d’analyses financières.pdfCOURS ANALYSE FINANCIERE-NOGLO Méthodes d’analyses financières.pdf
COURS ANALYSE FINANCIERE-NOGLO Méthodes d’analyses financières.pdf
sieousse95
 
Quelles rotations dans les systèmes caprins de Nouvelle-Aquitaine et Pays de ...
Quelles rotations dans les systèmes caprins de Nouvelle-Aquitaine et Pays de ...Quelles rotations dans les systèmes caprins de Nouvelle-Aquitaine et Pays de ...
Quelles rotations dans les systèmes caprins de Nouvelle-Aquitaine et Pays de ...
Institut de l'Elevage - Idele
 
Presentation d'esquisse route juin 2023.pptx
Presentation d'esquisse route juin 2023.pptxPresentation d'esquisse route juin 2023.pptx
Presentation d'esquisse route juin 2023.pptx
imed53
 
1er webinaire INOSYS Réseaux d’élevage Ovins Viande
1er webinaire INOSYS Réseaux d’élevage Ovins Viande1er webinaire INOSYS Réseaux d’élevage Ovins Viande
1er webinaire INOSYS Réseaux d’élevage Ovins Viande
Institut de l'Elevage - Idele
 
Présentation PFE (MOUAD LAZRAK) (2).pptx
Présentation PFE (MOUAD LAZRAK) (2).pptxPrésentation PFE (MOUAD LAZRAK) (2).pptx
Présentation PFE (MOUAD LAZRAK) (2).pptx
khalilbatariagro
 
Comment aborder le changement climatique dans son métier, volet adaptation
Comment aborder le changement climatique dans son métier, volet adaptationComment aborder le changement climatique dans son métier, volet adaptation
Comment aborder le changement climatique dans son métier, volet adaptation
Institut de l'Elevage - Idele
 

Dernier (7)

Alternative - Complément au Tramway et 3ème lien de la ville de Québec
Alternative - Complément  au Tramway et 3ème lien de la ville de Québec  Alternative - Complément  au Tramway et 3ème lien de la ville de Québec
Alternative - Complément au Tramway et 3ème lien de la ville de Québec
 
COURS ANALYSE FINANCIERE-NOGLO Méthodes d’analyses financières.pdf
COURS ANALYSE FINANCIERE-NOGLO Méthodes d’analyses financières.pdfCOURS ANALYSE FINANCIERE-NOGLO Méthodes d’analyses financières.pdf
COURS ANALYSE FINANCIERE-NOGLO Méthodes d’analyses financières.pdf
 
Quelles rotations dans les systèmes caprins de Nouvelle-Aquitaine et Pays de ...
Quelles rotations dans les systèmes caprins de Nouvelle-Aquitaine et Pays de ...Quelles rotations dans les systèmes caprins de Nouvelle-Aquitaine et Pays de ...
Quelles rotations dans les systèmes caprins de Nouvelle-Aquitaine et Pays de ...
 
Presentation d'esquisse route juin 2023.pptx
Presentation d'esquisse route juin 2023.pptxPresentation d'esquisse route juin 2023.pptx
Presentation d'esquisse route juin 2023.pptx
 
1er webinaire INOSYS Réseaux d’élevage Ovins Viande
1er webinaire INOSYS Réseaux d’élevage Ovins Viande1er webinaire INOSYS Réseaux d’élevage Ovins Viande
1er webinaire INOSYS Réseaux d’élevage Ovins Viande
 
Présentation PFE (MOUAD LAZRAK) (2).pptx
Présentation PFE (MOUAD LAZRAK) (2).pptxPrésentation PFE (MOUAD LAZRAK) (2).pptx
Présentation PFE (MOUAD LAZRAK) (2).pptx
 
Comment aborder le changement climatique dans son métier, volet adaptation
Comment aborder le changement climatique dans son métier, volet adaptationComment aborder le changement climatique dans son métier, volet adaptation
Comment aborder le changement climatique dans son métier, volet adaptation
 

cyberun #27

  • 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 !