Que peut faire une entreprise contre les initiés malhonnêtes et affectant négativement les infrastructures essentielles?
En 2013, un employé de Citibank a eu une mauvaise évaluation des performances qui l'a coché. Les résultats ont été dévastateurs:
Plus précisément, vers 18 h 03. ce soir-là, Brown a sciemment transmis un code et une commande à 10 routeurs Citibank Global Control Center, et en transmettant ce code, a effacé les fichiers de configuration en cours d'exécution dans neuf des routeurs, entraînant une perte de connectivité pour environ 90% de tous les réseaux Citibank. à travers l'Amérique du Nord.
Maintenant, il y a une question à propos de sécuriser un réseau contre les attaques de l'intérieur , mais cette question exclut explicitement les initiés qui deviennent voyous. Il y a aussi une question sur protéger une base de données contre les initiés , mais cela concerne des problèmes de haut niveau.
J'ai également lu Quelle est la procédure à suivre contre une faille de sécurité? , mais la plupart des réponses là-bas agissent en fonction de l'initié étant un employé qui a été licencié. Je pose des questions sur quelqu'un qui n'a pas encore été renvoyé. Ils ont peut-être eu une mauvaise évaluation des performances, mais n'ont pas encore été résiliés. Ils pourraient simplement être mécontents de quelque chose que leur partenaire a fait, ou ils pourraient avoir été contrariés par quelque chose.
Le problème que je décris ici est une grande entreprise où un utilisateur qui n'est pas satisfait de son travail se déclenche un certain jour et émet des commandes de rupture de système qu'il a tous les privilèges pour émettre. Des choses comme des machines à essuyer, endommager physiquement l'infrastructure essentielle, ... des interférences purement techniques, rien de tel qu'une fuite de courriels ou de secrets. Le but est simplement de faire le plus de dégâts possible à l'infrastructure pour sortir avec fracas.
L'article donne quelques mentions superficielles de choses à faire, mais rien de vraiment concret. Quelles mesures peuvent être prises pour empêcher que des initiés voyous soudains n'affectent négativement l'infrastructure essentielle en utilisant des techniques qu'ils ont le privilège de faire?
Règle à deux - configurez vos systèmes pour que tout accès privilégié nécessite deux personnes.
Cela pourrait être un contrôle physique - l'accès privilégié ne peut provenir que du CNO, et à l'intérieur du CNO, les gens appliquent physiquement la règle.
Plus pratique serait un système de script. Les administrateurs système n'ont pas directement accès à root, mais ils peuvent soumettre des scripts à exécuter en tant que root. Ils ne seront exécutés qu'après qu'une personne distincte aura examiné et approuvé le script. Il faudrait encore une méthode d'accès SSH en cas d'urgence - et la règle des deux hommes pourrait être maintenue dans ce cas en utilisant des contrôles physiques.
Le la NSA l'a implémenté après les fuites de Snowden. Je n'ai jamais vu un système complet à deux dans aucun des systèmes commerciaux ou gouvernementaux que j'ai audités - bien que j'aie vu diverses tentatives partielles.
Mise à jour - il y a plus d'informations sur la façon de l'implémenter sur un question séparée .
Quelles mesures peuvent être prises pour empêcher que des initiés voyous soudains n'affectent négativement l'infrastructure essentielle en utilisant des techniques qu'ils ont le privilège de faire?
En pratique, très peu . Mais pour expliquer pourquoi, permettez-moi de parler de ce que vous pouvez faire.
Le problème ici est que l'utilisateur est "privilégié" - il a légitimement obtenu le pouvoir.
Certaines mesures peuvent être prises pour limiter le pouvoir accordé aux utilisateurs légitimes, même aux administrateurs privilégiés:
- Contrôle des commandes disponibles en utilisant quelque chose comme Sudo ou PowerBroker.
- Double commande (la "règle des deux hommes" @ paj28 décrit
- Contrôles de workflow (qui sont souvent une forme de double contrôle)
Maintenant, ces contrôles sont beaucoup moins utilisés qu'ils ne le pourraient. Pourquoi? Parce que les utilisateurs privilégiés sont approuvés par définition. Je dis donc très peu non pas parce qu'il n'y a pas de contrôles, mais parce que le rapport coût-bénéfice de ces contrôles lorsqu'ils sont appliqués à du personnel de confiance n'est pas suffisant pour justifier il.
Notez également que le vecteur d'attaque ici était "dans la plomberie" - si Citibank a deux contrôles, ils sont probablement concentrés sur des choses comme les transferts de fonds, alors que cette attaque est intervenue au niveau des genoux et a simplement détruit le réseau sous-jacent. Ces systèmes vitaux mais silencieux ont souvent de plus petits cercles d'utilisateurs privilégiés et des contrôles moins excessifs.
Le véritable échec ici n'était pas qu'il n'y avait pas de contrôles techniques, mais que les contrôles du personnel avaient lamentablement échoué. Il est de pratique courante de révoquer l'accès des employés privilégiés avant ils sont résiliés. Celui qui a décidé qu'aucune précaution de ce type n'était nécessaire lors de l'introduction d'un conflit avec un employé privilégié a fait preuve d'un mauvais jugement.
(La société a également utilisé des contrôles punitifs - l'attaquant est maintenant condamné à près de 2 ans de prison et doit payer près de 80 000 $. Comme le souligne l'article, ces choses ne résolvent rien de tout cela.)
Une approche consiste à accepter que les actions frauduleuses ne peuvent être empêchées et à se concentrer sur la réparation des dommages. Par exemple, assurez-vous que les routeurs ont un plan de contrôle distinct via lequel ils peuvent être remis en ligne. Assurez-vous d'avoir des sauvegardes en lecture seule (par exemple, des bandes hors site), donc si quelqu'un efface tous les disques durs, vous pouvez récupérer les données. Assurez-vous que les données et le code peuvent être restaurés rapidement à un bon état connu.
Ces garanties seront également très utiles en cas d’erreurs involontaires.
Audit. En particulier le trafic réseau et effectué des actions/opérations sur des machines particulières. Vous voulez capturer, qui l'a fait quoi, quand ils l'ont fait et de où. Bien que cela n'empêche pas une attaque, cela aidera à dissuader de telles actions si l'initié croit qu'elles seront identifiées et capturées.
Ensuite, vous devez aborder la question des mécanismes d'audit inviolables
La question de la protection d'un système ou d'un réseau contre un initié, plus précisément contre les personnes dont la description de poste comprend la création et la gestion d'un tel système a toujours été délicate.
Tout d'abord, ce qu'il faut comprendre, c'est qu'en fin de compte, il est totalement impossible d'empêcher toutes sortes d'attaques contre une infrastructure de l'intérieur, car cela impliquerait de restreindre tout contact avec l'infrastructure, la rendant particulièrement inutile.
Cependant, il existe des moyens de prévenir et de minimiser tout dommage au système. Pour ce processus, je reconnais personnellement qu'il y a trois étapes:
- La règle des deux hommes
- La règle de responsabilité
- Division du travail
Ces processus se complètent pour aider tout système à rester à l'abri des intrus travaillant de l'intérieur.
La règle des deux hommes
Commençons par la plus évidente, la règle des deux hommes. Un élément important de la sécurité informatique et de l'infrastructure est de s'assurer que tout le comportement à l'intérieur du système est identifiable et souhaité. Cela implique que toute action entreprise à l'intérieur du système est fiable .
En montrant un exemple de cela, ma façon préférée d'expliquer est le système Git de Forking and Pulling. Dans Git, tout le monde ayant accès au référentiel (l'infrastructure dans ce cas) peut faire une copie. Ensuite, les personnes autorisées peuvent demander à extraire leur code dans le référentiel. Cependant, pour que cela se produise, le code extrait doit être analysé, marqué comme compatible, puis autorisé par quelqu'un d'autre.
La même chose pourrait être dite et faite pour une infrastructure sécurisée. Tout le personnel de gestion peut changer le code, mais pour que les changements entrent en production, ils doivent être approuvés par un ou plusieurs employés.
La règle de responsabilité
Un autre problème courant avec certains types de systèmes et réseaux est qu'il existe un seul compte de gestion dont le mot de passe est connu de tous les membres ayant accès. Le premier problème de responsabilité est soulevé ici. De nombreuses entreprises, lorsqu'elles se trouvent dans des situations de membres non autorisés effectuant des modifications non autorisées sur le serveur, s'appuient sur des méthodes primitives telles que la vérification de l'adresse IP de la machine, pour localiser qui a pu publier des modifications sur le système. Cela peut être simplement résolu en s'assurant que chacun a son propre compte et en lui faisant savoir que ses modifications sont enregistrées.
Comme mentionné dans le dernier paragraphe, la journalisation est le deuxième problème. La question de confiance refait surface dans ce cas. Comme le membre est de confiance pour apporter certaines modifications au système, le système ne consigne pas correctement les actions de l'utilisateur dans la plupart des cas.
Cette situation est le point idéal pour mettre en œuvre la responsabilité de l'action. L'utilisateur de gestion doit être conscient que non seulement ses actions sont suivies à tout moment lors de la modification de l'infrastructure, mais qu'il aura également des responsabilités contractuelles et des sanctions pour les actions délibérées.
Division du travail
Il s'agit d'un autre concept négligé dans la plupart des postes de direction de l'infrastructure informatique. Les équipes informatiques ont tendance à diviser leurs tâches, cependant, il n'est pas rare que la plupart des utilisateurs aient accès pour effectuer n'importe quelle tâche .
Le meilleur moyen d'éviter cela est de confier des tâches spécifiques de gestion du système à seulement deux personnes (pour éviter les cas où une seule personne n'est pas disponible). Alors que d'autres utilisateurs peuvent toujours vérifier et approuver les modifications, en utilisant la règle des deux hommes , seule une poignée d'utilisateurs peut réellement commencer ces modifications en premier lieu.
Suggestion personnelle
Une façon préférée de mettre en œuvre la sécurité à l'échelle du système, en particulier dans les grands environnements commerciaux, est d'avoir 3 ensembles de serveurs. Alpha, Beta et Production, les deux premiers étant un clone de ce dernier. Tout le monde peut déplacer des modifications vers Alpha, nous utilisons ce système pour tester comment il réagirait en production. La version bêta concerne les modifications qui ont été testées et sont prêtes à être déployées. Pour atteindre cette étape, plusieurs membres (~ 5) du service informatique doivent approuver le changement. À ce stade, le service informatique documente également les modifications et les envoie à la direction et sous forme de mémo au service informatique. Pour atteindre la production, 3 membres de la haute direction doivent approuver la modification, en utilisant leurs propres comptes, auxquels le service informatique n'a pas accès.
Dernière note
Comme vous l'avez peut-être remarqué, ce n'est pas un processus facile. La mise en œuvre d'un grand nombre de ces idées ralentira la production. C'est l'une des questions essentielles de la sécurité. Plus un système est sécurisé, plus il devient difficile de changer et de modifier. Pour rendre votre entreprise productive, vous devez équilibrer Sécurité et Confiance .
En garantissant que les commandes susceptibles d'affecter négativement les infrastructures de telle manière qu'elles ne soient pas accessibles à distance, ne peuvent être exécutées que localement.
Cela peut être réalisé de plusieurs manières. Par exemple, interdire la commande d'arrêt. Une autre façon consiste à avoir un chien de garde (dispositif matériel qui détecte les changements de disponibilité) qui redémarrera ladite infrastructure ou exécutera une procédure de récupération si l'infrastructure devient inaccessible.
Une troisième façon consiste à garantir l'accès à distance, en utilisant par exemple des solutions KVM sur IP, puis en liant ces ressources à des contrôles qui ne peuvent être manipulés que sur site. Ainsi, si une infrastructure est détruite, elle peut facilement être restaurée à distance.
Bien sûr, il est important d'avoir des sauvegardes des fichiers de configuration, des systèmes importants et autres. Étant donné que les fichiers de configuration sont rarement modifiés, je dirais qu'une sauvegarde des fichiers de configuration serait une bonne chose à faire après chaque changement de configuration qui est décidé à être validé.
Dans le cas où il est nécessaire de déconnecter l'infrastructure en raison d'événements de sécurité critiques, un système d'urgence peut être utilisé, qui déconnectera l'infrastructure de manière à ce qu'elle soit facilement récupérable par la direction, sans nécessiter de visite sur place.
Le problème ici n'était vraiment pas cet employé voyou. Et si cet employé faisait exactement la même chose, mais par erreur. Disons que son intention était de réparer un périphérique réseau défectueux, sans se rendre compte que l'équipement sera mis hors ligne après une suppression de configuration, et fait le code et la commande particuliers mentionnés dans la question, avec l'intention de recréer le fichier de configuration après qu'il ait été effacé, mais après avoir exécuté la commande, réalisant "oups, je ne peux plus me connecter à l'appareil".
Et provoque donc le même type de dommages? Croyez-moi, j'ai fait la même erreur, principalement avec mes propres systèmes, qui m'ont ensuite obligé à visiter l'emplacement physique de l'équipement. (mais dans ce cas, les choses n'étaient pas critiques, mais si les systèmes sont critiques, vous devez y faire quelque chose)
C'est pourquoi il doit exister des sécurités, il est donc impossible de provoquer ce type de dommage à distance, intentionnel ou non.
Beaucoup de bonnes réponses ici, mais une qui semble manquer est d'embrasser le Principe du moindre privilège (PoLP). S'il n'y a pas de cas d'utilisation légitime pour effacer les fichiers de configuration du routeur, n'autorisez personne à le faire. S'il existe un cas d'utilisation légitime mais qu'il n'est pas pertinent pour les opérations quotidiennes, exiger (et auditer) un processus d'approbation pour obtenir ce privilège (il s'agit en fait d'une variante de la règle des deux hommes qui ne s'applique qu'aux opérations particulièrement sensibles).
Il existe également des sauvegardes et des coffres-forts. Pour prendre l'exemple d'origine, si la configuration d'un routeur est effacée, il devrait revenir à une configuration de sécurité intégrée inamovible (et déclencher une alarme). Cela devrait également se produire en cas d'échec d'un contrôle de santé interne. Alternativement, si vous avez des contrôles d'intégrité, vous pouvez faire revenir le système à une "dernière bonne configuration connue", se restaurant essentiellement à partir d'une sauvegarde en cas de problème. L'accès en écriture à ces contrôles de sécurité/sauvegardes/d'intégrité doit être soumis à une sécurité extrêmement stricte - personne ne devrait disposer de privilèges quotidiens ou pouvoir pour obtenir facilement de tels privilèges - de sorte que même l'initié le plus fiable ne peut pas les contourner ou les écraser unilatéralement.
De toute évidence, toutes ces solutions auront des coûts. Il y a presque toujours un compromis entre la sécurité et les ressources dépensées (généralement décrites comme "commodité", mais les ressources peuvent également être du temps et/ou de l'argent). Un très bon PoLP signifie que personne n'a un véritable accès root (au niveau de Dieu) à quoi que ce soit, par exemple, ce qui ralentit les choses pour les personnes qui peuvent probablement faire confiance à autant d'accès (vous ne pouvez jamais vraiment savoir). Le code à sécurité intégrée est plus difficile à écrire que le code qui fait simplement confiance à toutes les commandes qu'il alimente à partir d'une source "digne de confiance", même si cette commande est HCF . La paranoïa a son prix ... mais ce prix pourrait bien être inférieur à ce qu'il en coûte si vous perdez 90% de votre connectivité réseau.
Un seul employé ne devrait jamais avoir le pouvoir de causer des dommages aussi répandus. De telles actions administratives devraient toujours nécessiter une authentification par deux administrateurs distincts ou plus, où le système d'authentification ne peut être désactivé que par les administrateurs de niveau supérieur.
Dans le cas où cela se serait déjà produit, l'employeur aurait le droit de licencier l'employé.
Dans chaque entreprise, ce que j'ai vu, il y avait aussi des règles de sécurité interne très strictes. Nous ne pouvions rien voir des autres projets, seulement nos tâches réelles.
Si nous nous déplaçions entre les projets/départements, nos autorisations étaient toujours affinées avec précision.
Seul un ensemble restreint d'administrateurs système avait accès à de grandes parties de l'infrastructure, ils y travaillaient tous au moins 5 à 10 ans. Personne n'avait probablement accès à l'ensemble du réseau.
La connexion n'importe quoi au réseau de l'entreprise sans autorisation explicite (il était même vain de le demander) était toujours strictement interdite. Une fois que j'ai connecté mon smartphone au port USB (uniquement pour le charger), en 5 minutes, mon collègue m'a demandé ce que je fais.
Nos ordinateurs/ordinateurs portables nous ont été remis pré-installés avec les certificats de l'entreprise. Après avoir quitté l'entreprise, nous les avons rendus.
Il y avait des contrôles de sécurité réguliers, ceux-ci étaient effectués par une entreprise externe (-> personne ne savait, quoi et comment ils faisaient). Nos logiciels, ce que nous avons produit, ont également été examinés par eux.
Ce que nous avons fait sur le réseau de l'entreprise, a probablement été enregistré et sauvegardé jusqu'à l'éternité.
Si nous avions fait des doutes, nous ne savions pas comment les journaux seront stockés et examinés. Après avoir quitté l'entreprise, nos ordinateurs ont également fait l'objet d'un contrôle de sécurité par la société externe, et probablement sauvegardés au niveau du secteur, pour le cas d'un "problème" apparu plus tard, pour servir de preuve.