Certains membres de notre groupe d'infrastructure souhaitent effectuer une mise à niveau pour commencer à profiter des nouvelles fonctionnalités de RHEL 6. Dans le passé, je me suis appuyé sur le guide de la NSA (www.nsa.gov/ia/_files/os/redhat/rhel5-guide- i731.pdf) pour sécuriser les installations RHEL 5 et CentOS 5. Je trouve ce guide inestimable.
Quelqu'un a-t-il de l'expérience dans la sécurisation de RHEL / CentOS 6 de la même manière? Si oui, quelles ressources (écrites ou consultatives) avez-vous utilisées?
Certains collègues m'ont dit que la version 6 est très différente de la version 5 de diverses manières, donc je ne veux pas laisser de trous béants dans notre sécurité parce que je n'ai pas suffisamment tenu compte de ces différences.
Le propre guide de Red Hat pour RHEL 6 ( http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/index.html ) est-il vraiment suffisant?
Est-ce que quelqu'un irait jusqu'à dire que, à moins que vous n'ayez une raison fonctionnelle impérieuse, vous devriez suspendre la mise à niveau de 5 à 6 jusqu'à ce qu'un groupe comme la NSA puisse produire un guide spécifique à la version que vous essayez de protéger?
J'apprécie tout commentaire que vous pourriez avoir, même s'il me dirige vers un forum plus approprié.
Cordialement,
Mike
la source
Réponses:
Mike,
il existe généralement quelques sources de bons guides pour renforcer la sécurité.
Dans mon travail, nous utilisons une combinaison des DISA STIG, ainsi que des marionnettes pour Linux. Je serais plus susceptible de dire que c'est insuffisant et de pousser pour certaines des recommandations ci-dessous.
Gardez à l'esprit que les guides de durcissement ci-dessus ont un chevauchement et certaines zones manquantes. Une meilleure pratique consiste à suivre toutes les options de configuration via un guide dans une base de données ou une feuille de calcul, afin que vous puissiez avoir la plus grande couverture.
Une autre façon de faire la même chose consiste à créer des scripts de renforcement ou d'audit basés sur ce qui précède, puis à exécuter des audits de vous-même pour déterminer où se trouvent les écarts entre les différentes normes.
Je ne pense pas que les guides de RHEL soient suffisants - je préfère les sorties de la NSA, DISA et NIST. Mais les guides de Red Hat sont un excellent point de départ.
Alors que la NSA et la DISA commencent à travailler sur le durcissement des normes bien à l'avance, dans le projet, cela peut être une bonne source pour vous. Si vous avez un ami dans DoD, vous pouvez également accéder au matériel de pré-version. En raison de l'état actuel de la DISA STIG pour Red Hat, je dirais que la NSA est susceptible de produire quelque chose plus rapidement. Je peux vérifier avec eux et voir où ils se trouvent. Je recommanderais de commencer à passer à 6 dans un environnement de test dès maintenant. Faites tester vos scripts de renforcement en 6.
Faire appel à une assistance extérieure pour élaborer des directives de renforcement de la sécurité
Envisagez un engagement avec un ingénieur en sécurité axé spécifiquement sur le renforcement de la sécurité Linux pour vous fournir des conseils. Red Hat peut également mettre ses employés à disposition pour des missions afin d'accélérer les efforts d'ingénierie de sécurité.
Tout ce que vous avez dit jusqu'à présent indique une approche de diligence raisonnable et une sécurité raisonnable. Sur cette base, je pense qu'en considérant ci-dessus, vous êtes clair pour passer à RHEL6. Cependant, je vais ajouter quelques tâches supplémentaires que vous pourriez envisager car je suppose que vous travaillez dans un environnement réglementé très soucieux de la sécurité.
Augmentez votre approche avec une évaluation des risques
Si vous vouliez faire passer votre approche au niveau supérieur et la justifier d'une manière qui passerait le contrôle même par l'auditeur le plus fidèle, envisagez d'effectuer une évaluation complète des risques de développement à l'aide du NIST 800-30 avec les ensembles de contrôles particuliers utilisés dans votre industrie. Ceci, soutenu par des tests et analyses de sécurité. La formalisation d'une évaluation des risques permettra une bonne documentation des risques présentés en allant de l'avant avec RHEL6, et certains contrôles compensatoires potentiels que vous pourriez ajouter pour pallier toute faiblesse potentielle.
Ajout d'un test de pénétration
En allant même au-delà de l'évaluation des risques, vous pouvez engager un testeur de pénétration avec une solide expérience Linux pour tenter des pénétrations en boîte blanche ou en boîte noire de votre hôte RHEL6 après certaines configurations sécurisées. Un système d'exploitation de base sécurisé peut ne pas présenter beaucoup de surface d'attaque, donc le charger avec des applications présenterait une plate-forme d'attaque beaucoup plus réaliste qui vous permettrait de mieux comprendre les vecteurs d'attaque potentiels. En tournant autour à la fin, en utilisant le rapport de test du stylo, vous pouvez augmenter votre travail précédent, combler les lacunes, ajouter des contrôles supplémentaires et vous diriger vers les opérations avec beaucoup plus de chaleur et de flou.
la source
Les RHEL 6 STIGS devraient être terminés vers le 13 mai 2013. Vous pouvez suivre les informations sur la liste de diffusion Gov-Sec de Red Hat.
la source