Avant que la défense en profondeur ne soit établie, est-il passif d'être battu ? Vous devez faire quelques choses de base pour maximiser votre stop loss. Même si certaines choses peuvent paraître simples, elles sont souvent à l'origine d'incidents de sécurité.
La première étape est la mise en œuvre des politiques de sécurité de base. Cette partie peut paraître moins haut de gamme, mais c’est la partie avec le ROI le plus élevé. La majeure partie de cette partie est un élément de rectification, et 80 % des problèmes de sécurité peuvent être évités sans trop d'investissements supplémentaires. Même si une entreprise ne dispose pas d'un budget de sécurité important et ne peut pas assurer une sensibilisation aux intrusions en temps réel dans l'ensemble de son activité, elle peut toujours avoir une garantie de base pour le résultat net.Cette étape appartient généralement à « mourir de faim ».
La deuxième étape consiste à entrer dans la construction systémique, qui implique les méthodes de défense sécuritaire dans toutes les dimensions. La détection des intrusions, etc., outre la technologie, inclut également des exigences en matière de processus et d'audit. Il s'agit d'un prototype relativement systématique. Pour les sociétés Internet qui ne sont pas particulièrement grandes, logiciels open source + solutions commerciales peuvent généralement y faire face. À ce stade, si la cible est une grande entreprise Internet, elle devrait s'engager directement sur la voie de l'auto-recherche et commencer simultanément à développer des produits de sécurité, tels que HIDS, les plateformes Big Data, etc. nécessité pratique inévitable.
Dans la troisième étape, après l'intégration systématique de la construction, de l'exploitation et de la maintenance de la sécurité et de SDL dans le système, vous pouvez vous concentrer de manière sélective sur les problèmes de sécurité de l'entreprise. Habituellement, la sécurité des comptes est utilisée comme point de départ, puis les activités de processus informatiques présentant les risques les plus élevés dans l'activité principale sont sélectionnées pour mener une analyse pertinente des risques commerciaux et la construction d'un système de contrôle des risques commerciaux.
Lorsque l’exploitation et la maintenance de la sécurité, la sécurité des produits (SDL) et la sécurité de l’entreprise sont initialement regroupées en un système, la construction globale de la sécurité est-elle terminée ? Évidemment pas. Avec ces points et surfaces, nous pouvons seulement dire qu'il existe un squelette. Tout au plus, il ne peut être considéré que comme un réseau de défense d'épaisseur inégale. Les points faibles sont encore faciles à pénétrer. Par conséquent, le prochain travail consiste à entrer le lien opérationnel, qui est ce qu'on appelle le travail PDCA, polissant chaque point défensif à l'extrême. Cette partie du travail est très importante, mais il s'agit d'une « compétence interne » qui n'est pas visible à la réception. Elle n'est peut-être pas facilement prise au sérieux par les managers, mais le responsable de la sécurité doit connaître les enjeux, comment investir des ressources dans cette partie du travail et quantifier les résultats des KPI correspondants.Questions à considérer.
Au dernier niveau, lorsque la construction des points et aspects ci-dessus est presque peaufinée, la construction de sécurité entre dans la « zone de jeu libre ». Les choses faites dans cette zone sont souvent liées à l'état de fonctionnement de la plate-forme, à la position du marché l'activité et la nature mondiale de l'entreprise. Cela y est pour beaucoup. Il n'est plus possible d'étiqueter des choses dans cette gamme, mais il existe certaines références qui peuvent être suivies, comme l'analyse comparative avec les principaux fabricants du secteur. .
(1) Organisation
Il existe SRC. SRC n'est pas seulement une plate-forme pour soumettre des vulnérabilités pour obtenir des commentaires de récompense, mais aussi un canal pour entretenir des relations noires et blanches. Avec les canaux relationnels, vous pouvez obtenir des informations payantes du premier coup (les renseignements sur les menaces sont un concept, en fait , l'information a une valeur), ce type de renseignement n'est pas nécessairement un IOC lisible par machine, il s'agit probablement d'une phrase "Votre système xx a été piraté, vous revenez en arrière et vérifiez". Maintenant, le modèle SRC se joue la guerre populaire.. Goût, toutes les ressources doivent être mobilisées pour signaler une information menaçante. L'équipe SRC, plus mature, fait également une chose supplémentaire : l'analyse des causes profondes et de l'impact de la vulnérabilité, et l'équipe SRC n'intervient pratiquement plus dans les processus ultérieurs.
Les trois départements fonctionnels typiques sont : l'exploitation et la maintenance, l'équipe de développement de produits et l'équipe de construction de systèmes de défense au sein du département de sécurité. Voici la répartition des tâches de ces trois départements :
1) L'équipe d'exploitation et de maintenance est responsable de la mise en œuvre spécifique des correctifs et des modifications de configuration liées aux systèmes, aux bases de données, aux middlewares et à l'infrastructure réseau, telles que les vulnérabilités des logiciels serveur open source tiers Nginx, OpenSSL et MySQL.
2) L'équipe produit est chargée de corriger les vulnérabilités au niveau du code liées au produit (s'il s'agit d'une vulnérabilité dans un produit auto-développé).
3) L'équipe de construction du système de défense de sécurité est responsable de la mise à jour des règles de détection correspondant à la vulnérabilité dans le système de sensibilisation aux intrusions concerné.
(2) Processus
1) Les vulnérabilités générales sont les mêmes que lors du processus de correction de bugs ordinaire. Elles sont transférées de l'interface du service de sécurité vers l'interface métier. Après cela, le service commercial répare et soumet une nouvelle version pour publication. Il suit le processus de publication DevOps ordinaire. et il n'y a rien de spécial là-dedans. Quant au processus PDCA de « réparation-vérification-libération-surveillance » de la vulnérabilité elle-même, il est couvert par DevOps et est le même que la version ordinaire.
2) Pour les vulnérabilités plus graves, les responsables des trois fonctions de sécurité, d'exploitation et de maintenance, ainsi que de produit, organisent généralement une réunion pour formuler des correctifs spéciaux pour les vulnérabilités et des plans d'urgence. Dans ce scénario, l’effet d’une réunion temporaire en présence d’acteurs clés est bien plus important que la formulation d’un processus. Le processus peut être là, mais il n’est pas le point central. Pour le dire graphiquement, nous avons une réunion le matin pour formuler un plan, mettre en œuvre la publication à midi et poursuivre la surveillance le soir. Cela peut être fait en une journée. Le processus implique principalement de prendre des mesures d'évitement des risques en référence à ITIL.
3) SLA - Déterminé en fonction du type de vulnérabilité et de son impact. Les vulnérabilités générales n'ont pas besoin d'être réparées du jour au lendemain. Pour les vulnérabilités à haut risque, s'il existe une surface d'attaque réelle, le travail sera effectué du jour au lendemain. L'ensemble du patch push du réseau pour les vulnérabilités à haut risque peut être terminé dans les 24 heures. De manière générale, cet indicateur est lié aux capacités automatisées d'exploitation et de maintenance. , mais la confirmation de la zone d'impact et de l'étendue des dégâts reste une responsabilité de sécurité.
4) S'il ne peut pas être réparé dans un court laps de temps, utilisez des mesures de contournement temporaires. Le périphérique frontal fournit un "correctif virtuel", qui est une règle de blocage pour la vulnérabilité (à condition que cette fonctionnalité soit disponible), ou ferme certaines fonctions. à court terme et ajouter des moyens de contrôle d'accès comme mesures de contournement temporaires.
(3) Technologie
1) La détection rapide repose sur le système de perception des intrusions, qui constitue le cœur du système de protection de la sécurité Internet dans diverses dimensions telles que l'audit HIDS, RASP, WAF et SQL.
2) La réparation rapide repose sur la prise en charge d'outils d'intégration continue et de publication automatisés. La façon dont les développeurs publient en un seul clic est une activité quotidienne des sociétés Internet. Cette capacité repose sur la construction d'outils de développement et d'outils d'exploitation et de maintenance, et ses responsabilités ne sont pas directement liée à la sécurité, mais elle a un impact potentiel sur l’efficacité de la réparation des vulnérabilités.
3) De même, les capacités d'exploitation et de maintenance automatisées relèvent principalement de la responsabilité de l'exploitation et de la maintenance, mais elles affecteront également l'efficacité de la réparation des vulnérabilités et la mise en œuvre des politiques de sécurité.
Pour résumer, il y a en réalité trois choses : 1) le découvrir rapidement ; 2) le réparer rapidement ; 3) s'il n'est pas réparable, il peut être temporairement évité.