Назад | Перейти на главную страницу

Все, что связано с руководством АНБ по обеспечению безопасности RHEL 6

Некоторые в нашей группе инфраструктуры хотят выполнить обновление, чтобы начать использовать новые функции в RHEL 6. В прошлом я полагался на Руководство NSA (www.nsa.gov/ia/_files/os/redhat/rhel5-guide- i731.pdf) для защиты установок RHEL 5 и CentOS 5. Я считаю это руководство бесценным.

Есть ли у кого-нибудь подобный опыт защиты RHEL / CentOS 6? Если да, то какие ресурсы (письменные или консультативные) вы использовали?

Я слышал от некоторых коллег, что версия 6 существенно отличается от версии 5 по-разному, поэтому я не хочу оставлять зияющие дыры в нашей безопасности, потому что я не учел должным образом эти различия.

Собственное руководство Red Hat для RHEL 6 (http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/index.html) действительно достаточно?

Может ли кто-нибудь зайти так далеко, чтобы сказать, что, если у вас нет веской функциональной причины, вам следует отложить обновление с 5 до 6 до тех пор, пока какая-то группа, такая как АНБ, не сможет подготовить руководство, специфичное для версии, которую вы пытаетесь защитить?

Я ценю любую обратную связь, которую вы можете получить, даже если она направляет меня на более подходящий форум.

С Уважением,

Майк

Майк,

как правило, существует несколько источников хороших руководств по усилению безопасности.

  • DISA STIGs
  • ГНБ АНБ
  • NIST
  • Индикаторы СНГ
  • Руководство поставщика
  • SANS
  • Книги по закаливанию

В моей работе мы используем комбинацию DISA STIG и puppet для Linux. Я бы с большей вероятностью сказал, что это неадекватно, и настаивал на некоторых из приведенных ниже рекомендаций.

Имейте в виду, что приведенные выше руководства по закалке частично совпадают, а в некоторых местах отсутствуют. Лучшая практика - отслеживать все параметры конфигурации с помощью руководства в базе данных или электронной таблице, чтобы обеспечить максимальный охват.

Альтернативный способ сделать то же самое - создать сценарии усиления или аудита на основе вышеизложенного, а затем провести собственный аудит, чтобы выяснить, где есть пробелы между различными стандартами.

Я не верю, что руководств RHEL достаточно - я предпочитаю результаты NSA, DISA и NIST. Но руководства Red Hat - отличная отправная точка.

Поскольку NSA и DISA начинают работать над ужесточением стандартов заранее, в черновике, это может быть для вас хорошим источником. Если у вас есть друг в DoD, вы также можете получить доступ к предварительным материалам. В связи с текущим состоянием DISA STIG для Red Hat я бы сказал, что АНБ, скорее всего, произведет что-то более быстрое. Я могу поговорить с ними и посмотреть, где они. Я бы порекомендовал начать переходить на 6 в тестовой среде прямо сейчас. Протестируйте свои скрипты усиления в версии 6.

Привлечение внешней помощи для разработки руководства по усилению безопасности

Рассмотрите возможность взаимодействия с инженером по безопасности, специально специализирующимся на усилении безопасности Linux, чтобы подготовить для вас руководство. Red Hat может предоставить своих сотрудников для участия в проектах, чтобы ускорить работу по обеспечению безопасности.

Все, что вы сказали до сих пор, указывает на проявление должной осмотрительности и разумной безопасности. Исходя из этого, я думаю, учитывая вышесказанное, вы можете перейти к RHEL6. Однако я собираюсь добавить некоторые дополнительные задачи, которые вы могли бы рассмотреть, поскольку я предполагаю, что вы работаете в регулируемой среде, которая очень заботится о безопасности.

Дополнение вашего подхода оценкой рисков

Если вы хотите вывести свой подход на следующий уровень и обосновать его таким образом, чтобы он прошел проверку даже самого внимательного аудитора, рассмотрите возможность проведения полноценной оценки риска развития с использованием NIST 800-30 вместе с конкретными наборами средств контроля, используемыми в вашем промышленность. Это подтверждается тестированием и анализом безопасности. Формализованная оценка рисков позволит хорошо документировать риски, связанные с продвижением RHEL6, а также некоторые потенциальные компенсирующие меры, которые вы могли бы добавить, чтобы подкрепить любые потенциальные недостатки.

Добавление теста на проникновение

Выйдя даже за рамки оценки рисков, вы можете привлечь тестера на проникновение с сильным опытом работы с Linux, чтобы попытаться проникнуть в ваш хост RHEL6 по принципу «белый ящик» или «черный ящик» после некоторых безопасных конфигураций. Защищенная базовая операционная система может не иметь большой поверхности для атак, поэтому загрузка в нее приложений представит гораздо более реалистичную платформу для атаки, которая поможет вам лучше понять потенциальные векторы атаки. Обойдя вокруг в конце, используя отчет теста пера, вы можете дополнить свою предыдущую работу, закрыть любые пробелы, добавить дополнительные элементы управления и перейти к операциям с гораздо более теплым и нечетким.

Ожидается, что RHEL 6 STIGS будет завершен примерно 13 мая 2013 года. Вы можете следить за информацией в списке рассылки Red Hat Gov-Sec.