Différence entre les guides de trempe (CIS, NSA, DISA)
Je recherche le renforcement du système d'exploitation et il semble qu'il existe une variété de guides de configuration recommandés. Je me rends compte que les différents fournisseurs de configuration fournissent différentes offres par système d'exploitation, mais supposons (pour plus de commodité) que nous parlons de Linux. Considérer ce qui suit :
Y a-t-il des différences évidentes entre celles-ci qui pourraient obliger quelqu'un à en choisir un plutôt que les autres?
Mise à jour: 2014-11-19
Contexte supplémentaire, par réponse aux soumissions qui demandaient des détails supplémentaires:
- Je n'ai pas besoin de me durcir par rapport à une référence ou à une directive donnée, j'essaie simplement de comprendre les meilleures pratiques actuelles utilisées dans l'industrie et le gouvernement. Cependant, je prévois de transformer mes résultats en un document de recherche pour la classe.
- Je ne serai pas audité, sauf par ceux qui liront mon article.
- Mon professeur et quelques étudiants connaissent peut-être le processus de vérification, mais j'espère rendre mon document accessible à tous. Je voudrais écrire sur la façon d'utiliser un outil pour analyser automatiquement un système selon certaines directives ou base de données de vulnérabilités. Je suis assez nouveau dans ce domaine, mais je recherche OpenSCAP et OpenVAS . OpenSCAP semble plus accessible qu'OpenVAS, et semble être écrit pour tester par rapport aux normes NIST . Je ne sais pas quels NIST sont testés par OpenSCAP, mais je vais ajouter NIST les directives NIST à ma liste de guides à considérer.
- Tate Hansen a suggéré d'utiliser Nessus pour la numérisation , cependant je voudrais m'en tenir strictement aux applications Open Source pour répondre à mes besoins pour cette recherche.
- Une sous-question, il semble que le guide des normes NIST pour le durcissement soit SP 800-12 et SCAP est simplement un format ( XML?) Pour les outils permettant d'effectuer et de communiquer l'analyse d'un système. Est-ce exact?
En général, les STIG DISA sont plus strictes que les références CIS. Gardez à l'esprit qu'avec les STIG, les configurations exactes requises dépendent de la classification du système basée sur la catégorie d'assurance de mission (I-III) et le niveau de confidentialité (classifié public), vous donnant neuf combinaisons possibles différentes d'exigences de configuration. Les CIS ont généralement des catégories de niveau un et deux.
OpenVAS répondra probablement à vos besoins en matière d'évaluation de référence/de référence. Nessus fonctionnera également et est gratuit pour une utilisation non commerciale jusqu'à seize adresses IP. Pour un usage commercial, c'est toujours assez abordable.
Je n'ai pas encore trouvé de tableau croisé complet pour ces différentes normes. La meilleure tentative que j'ai vue jusqu'à présent est ici (une copie des archives Web): http://www.dir.texas.gov/sitecollectiondocuments/security/texas%20cybersecurity%20framework/dir_control_crosswalk.xls . Cette feuille de calcul, cependant, est une comparaison des contrôles, pas une référence/des références qui, je pense, vous intéressent vraiment.
En ce qui concerne les exigences du NIST, oui 800-123 est le document de base qui requiert des systèmes pour implémenter les contrôles trouvés dans 800-53A. Ces exigences diffèrent des références en ce que les exigences NIST vous indiquent un contrôle qui doit être implémenté, mais pas exactement comment il doit être implémenté. Les Benchmarks sont généralement très spécifiques en ce que vous devez définir le paramètre X sur la valeur Y.
J'espère que cela t'aides.
Une différence est la facilité de trouver un outil fiable et automatisé pour vérifier la conformité. Je crois que Nessus a des modèles disponibles pour la plupart de ceux que vous avez répertoriés, mais certains sont datés. Dans tous les cas, je choisirais celui qui vous permet de vérifier et de rester en conformité aussi facilement que possible.
Voici quelques considérations importantes:
- Quelle est la raison pour laquelle vous vous endurcissez par rapport à une référence ou une directive donnée?
- Allez-vous être audité?
- Y a-t-il une voie préférée ou une voie que vos auditeurs connaissent mieux?
- Quels outils utiliserez-vous pour l'auto-vérification?
- Ces outils ont-ils des politiques ou des plugins pour auditer votre système par rapport à une référence donnée?
Si vous ne faites que durer votre système d'exploitation parce que quelqu'un vous a dit d'être `` sécurisé '', vous aurez moins de contraintes et pourrez accéder à chaque guide et choisir votre préférence. Tous les modèles de durcissement mentionnés produiront un système plus sécurisé.
Avant de répondre à votre question, je voudrais définir un mot que vous avez utilisé (durcissement). Selon le wiki omniscient, je le définirai comme "le processus de sécurisation d'un système en réduisant sa surface de vulnérabilité". Pour savoir quelle approche vous convient, vous devez savoir ce que vous espérez accomplir.
Certains dans le DoD (et d'autres industries) peuvent appliquer uniquement des STIG tandis que d'autres appliquent plus que des STIG. C'est ce qu'utilisent les ingénieurs en sécurité comme différence entre la conformité et la sécurité. La conformité consiste à cocher une case en disant que vous l'avez fait ... La sécurité consiste à cocher cette case et à chercher s'il y a autre chose que vous pouvez faire pour atténuer les faiblesses.
De plus, si vous regardez le STIG de sécurité et de développement des applications, il indique en fait: "L'IAO doit s'assurer si un guide DoD STIG ou NSA n'est pas disponible, un produit tiers sera configuré par le selon l'ordre décroissant suivant: 1) pratiques acceptées dans le commerce, (2) résultats de tests indépendants ou (3) documentation du fournisseur. "
Une chose que vous devez comprendre à propos de la politique du DoD, c'est que la politique au sommet n'est pas toujours la fin/tout-être. Il existe souvent des couches de politique qui doivent être suivies. Les politiques de niveau inférieur ne peuvent être que plus strictes, pas moins strictes. Donc, en substance, certains programmes peuvent être tenus d'appliquer toutes les recommandations. Cependant, ce que vous constaterez généralement, c'est qu'il y a souvent un chevauchement important.
En cas de directives contradictoires, la règle de priorité supérieure l'emporte sur la règle inférieure. Pour quelqu'un qui essaie de "durcir" un système, je dis pécher par excès de sécurité. Comprenez également que tout guide est rédigé par des personnes qui peuvent commettre des erreurs. C'est pourquoi il y a eu plusieurs révisions en raison de types-O et de malentendus sur une technologie.
Que se passe-t-il lorsque le guidage rompt quelque chose, c'est là que quelqu'un devra décider si le risque de X est supérieur au risque de ne pas pouvoir utiliser Y.