Que peut-on faire pour empêcher des initiés soudains et voyous d'avoir un impact négatif sur l'infrastructure essentielle en utilisant des techniques qu'ils ont le privilège de faire?

En pratique, très peu . Mais pour expliquer pourquoi, laissez-moi parler de ce que vous pouvez faire.

Le problème ici est que l'utilisateur est "privilégié" - il a reçu le pouvoir légitimement.

Il y a certaines choses qui peuvent être faites pour limiter le pouvoir donné 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 contrôle (la "règle de deux hommes" @ paj28 décrit
• Contrôles de flux de travail (qui sont souvent une forme de double contrôle)

Désormais, ces contrôles sont beaucoup moins utilisés qu'ils ne pourraient l'être. Pourquoi? Parce que les utilisateurs privilégiés sont par définition dignes de confiance . 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 ne suffit pas à le justifier.

Notez également que le vecteur d'attaque ici était "dans la plomberie" - si Citibank a deux contrôles, ils sont probablement axé sur des choses comme les transferts de fonds, alors que cette attaque est arrivée aux 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 leur licenciement. Quiconque a décidé qu'une telle précaution n'était pas nécessaire lors de l'introduction d'un conflit avec un employé privilégié a fait preuve d'un mauvais jugement.

(L'entreprise 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èglent rien de tout cela.)

Règle de deux hommes - configurez vos systèmes de sorte que tout accès privilégié nécessite deux personnes.

Cela peut être un contrôle physique - l'accès privilégié ne peut provenir que du NOC, et à l'intérieur du NOC, 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'une fois qu'une personne distincte aura examiné et approuvé le script. Il faudrait toujours une méthode d'accès SSH en cas d'urgence - et la règle des deux hommes pourrait être maintenue dans ce cas à l'aide de contrôles physiques.

La NSA a implémenté ceci après le Snowden fuit. Je n'ai jamais vu de système complet à deux dans aucun des systèmes commerciaux ou gouvernementaux que j'ai audités - bien que j'aie vu plusieurs tentatives partielles.

Mise à jour - il y a plus d'informations sur comment mettre en œuvre ceci sur une question distincte.

Une approche consiste à accepter que les actions malveillantes ne peuvent pas être empêchées et à se concentrer sur la réparation des dégâts. Par exemple, assurez-vous que les routeurs disposent d'un plan de contrôle séparé 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 mesures de protection aideront également beaucoup en cas d'erreurs involontaires.

Audit. En particulier le trafic réseau et les actions / opérations effectuées sur des machines particulières. Vous voulez capturer, qui a fait quoi , quand ils l'ont fait et depuis où . Bien que cela n'empêche pas une attaque, cela aidera à dissuader de telles actions si l'initié pense qu'elles seront identifiées et capturées.

Ensuite, vous devez vous lancer dans la question des mécanismes d'audit infalsifiables

La question de la protection d'un système ou d'un réseau contre un initié, plus particulièrement contre les personnes qui ont sa propre description de poste comprend la création et la gestion d'un tel système a toujours été délicate.

Premièrement, ce qu'il faut comprendre 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:

1. La règle des deux hommes
2. La règle de responsabilité
3. 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. Une partie importante 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 manière préférée d'expliquer est le système Git de Forking and Pulling. Dans Git, toute personne ayant accès au référentiel (The Infrastructure dans ce cas) peut faire une copie. Ensuite, les personnes ayant accès 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 direction peut modifier le code, mais pour que les modifications entrent en production, elles doivent être approuvées par un ou plusieurs membres du personnel.

La règle de responsabilité

Un autre problème courant avec certains types de systèmes et de réseaux est qu'il existe un 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 où des membres non autorisés effectuent 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 la confiance remonte à la surface dans ce cas. Comme le membre est digne de confiance pour apporter certaines modifications au système, le système n’enregistre pas dans la plupart des cas correctement les actions de l’utilisateur.

Cette situation est le point idéal pour mettre en œuvre la responsabilité des actions . 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 liées au contrat et des pénalités pour actions délibérées.

Division du travail

C'est un autre concept négligé dans la plupart des postes de direction d'infrastructure informatique. Les équipes informatiques ont tendance à diviser leurs tâches, mais il n'est pas rare que la plupart des utilisateurs aient accès pour effectuer n'importe quelle tâche.

La meilleure façon d'éviter cela est d'avoir tâches spécifiques de gestion du système assignées à seulement deux personnes (pour éviter les cas où une personne n'est pas disponible). Alors que les 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.

Suggestion personnelle

Un moyen préféré pour mettre en œuvre la sécurité à l'échelle du système, en particulier dans les grands environnements d'entreprise, consiste à disposer de 3 ensembles de serveurs. Alpha, Beta et Production, les deux premiers étant un clone de ce dernier. N'importe qui 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 accéder à la production, 3 membres de la direction de haut niveau doivent approuver le changement, en utilisant leurs propres comptes, auxquels le service informatique n'a pas accès.

Dernière remarque

Comme vous l'avez peut-être remarqué, ce n'est pas un processus facile. La mise en œuvre de plusieurs 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 veillant à ce que les commandes qui auraient un impact négatif sur l'infrastructure de telle manière qu'elle ne soit pas accessible à distance, ne puissent être exécutées que localement.

Ceci peut être réalisé de plusieurs manières. Par exemple, interdire la commande d'arrêt. Une autre façon est d'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 est d'assurer l'accès à distance, par for exemple en utilisant des solutions KVM sur IP, puis en liant ces ressources à des contrôles qui ne peuvent être manipulés que sur site. Ainsi, si l'infrastructure est mise hors service, elle peut être facilement restaurée à distance.

Bien sûr, il est important d'avoir des sauvegardes des fichiers de configuration, des systèmes importants, etc. É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 décidé à être validé.

Au cas où il serait nécessaire de déconnecter l'infrastructure en raison de problèmes critiques événements de sécurité, un système d'urgence peut être utilisé, qui déconnectera l'infrastructure d'une manière facilement récupérable par la direction, sans nécessiter une 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 comme une 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 un effacement de la configuration, et exécute cette commande & de code particulière mentionnée dans la question, avec l'intention de recréer le fichier de configuration après effacé, mais après avoir exécuté la commande, réalisant "oups, je ne peux plus vous connecter à l'appareil".

Et provoque donc le même type de dégâts? Croyez-moi, j'ai fait la même erreur, principalement avec mes propres systèmes, qui m'ont alors 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 devriez y faire quelque chose)

C'est pourquoi il doit exister des sécurités, il est donc impossible de causer ce type de dommage à distance , intentionnel ou non.

Beaucoup de bonnes réponses ici, mais une qui semble manquer est de adopter 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, ne donnez à personne l'accès pour le faire. S'il existe un cas d'utilisation légitime mais qu'il n'est pas pertinent pour les opérations quotidiennes, exigez (et auditez) 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'à opérations particulièrement sensibles).

Il y a aussi des sauvegardes et des sécurités. Pour prendre l'exemple d'origine, si la configuration d'un routeur est effacée, il doit revenir à une configuration de sécurité intégrée non amovible (et déclencher une alarme). Cela devrait également se produire en cas d'échec d'une vérification de l'état interne. Alternativement, si vous avez des contrôles de santé, vous pouvez faire revenir le système à une configuration "dernière bonne 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’état de sécurité doit être soumis à une sécurité extrêmement stricte - personne ne devrait avoir les privilèges quotidiens sur eux, ou être en mesure d’obtenir facilement ces privilèges - de sorte que même le plus Un initié de confiance 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 la dépense de ressources (généralement décrit comme «commodité», mais les ressources peuvent aussi être du temps et / ou de l'argent). Un très bon PoLP signifie que personne n'obtient 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 avec autant d'accès (vous ne pouvez jamais vraiment savoir ). Le code de sécurité est plus difficile à écrire que le code qui fait simplement confiance à toutes les commandes fournies par 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 étendus. Des actions administratives comme celle-ci devraient toujours exiger l'authentification par deux ou plusieurs administrateurs distincts, 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 dû tout droit de licencier l’employé.

Dans chaque entreprise que j'ai vue, il y avait également 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 précisément ajustées.

Seul un ensemble restreint de les administrateurs système avaient accès à de grandes parties de l'infrastructure, ils y travaillaient tous au moins 5 à 10 ans. Personne n'avait probablement accès à tout le réseau.

La connexion de quoi que ce soit au réseau de l'entreprise sans autorisation explicite (il était même impossible de demander cela) était toujours strictement interdite. Une fois que j'ai connecté mon smartphone au port USB (uniquement pour le charger), mon collègue m'a demandé en 5 minutes ce que je faisais.

Nos ordinateurs / ordinateurs portables nous ont été fournis pré-installés avec le certificats d'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 société externe (-> personne ne savait, quoi et comment). 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 l'avions fait tout doute, nous ne savions pas, comment seront stockés et examinés les journaux. Après avoir quitté l'entreprise, nos ordinateurs ont également fait l'objet d'un contrôle de sécurité par l'entreprise externe, et probablement sauvegardés au niveau du secteur, pour le cas d'un "problème" apparaissant plus tard, pour servir de preuve.