Следует сосредоточить внимание на двух важных областях:

1. Сложно попасть внутрь.
2. Создание политик и процедур для спокойной и эффективной обработки ситуации, когда кто-то попадает в прошлый пункт 1.

Трудно попасть внутрь

Это очень сложная тема, и большая часть ее сосредоточена на том, чтобы убедиться, что у вас достаточно информации, чтобы выяснить, что случилось постфактум. Абстрактные пункты для простоты:

• Вести журналы (см. Также Управление информационными событиями безопасности)
  • Любые попытки авторизации, как успешные, так и неудачные, желательно с неизменной исходной информацией.
  • Журналы доступа к межсетевому экрану (возможно, потребуется включить межсерверные межсетевые экраны, если они используются).
  • Журналы доступа к веб-серверу
  • Журналы аутентификации сервера баз данных
  • Журналы использования конкретных приложений
  • Если возможно, SIEM может выдавать предупреждения о подозрительных шаблонах.
• Обеспечьте надлежащий контроль доступа
  • Убедитесь, что права установлены правильно везде, и по возможности избегайте «ленивых прав» («о, просто дайте всем прочитать»).
  • Периодические проверки списков управления доступом, чтобы гарантировать, что процедуры действительно соблюдаются, и временные шаги по устранению неполадок («дайте всем прочитать, посмотрите, работает ли тогда») были правильно удалены после завершения устранения неполадок.
  • Все правила прохождения межсетевого экрана должны быть обоснованы и периодически проверяться.
  • Контроль доступа к веб-серверу также необходимо проверять, как списки управления доступом к веб-серверу, так и списки управления доступом файловой системы.
• Принудительное управление изменениями
  • Любые изменения в среде безопасности должны централизованно отслеживаться и проверяться более чем одним человеком.
  • Патчи должны быть включены в этот процесс.
  • Наличие общей сборки ОС (шаблона) упростит среду и упростит отслеживание и применение изменений.
• Отключите гостевые учетные записи.
• Убедитесь, что для всех паролей не установлены значения по умолчанию.
  • Стандартные приложения могут устанавливать для пользователей заранее заданные пароли. Измените их.
  • Многие ИТ-устройства поставляются с хорошо известными парами пользователь / пароль. Меняйте их, даже если вы заходите в эту штуку только раз в год.
• Практикуйте минимум привилегий. Предоставьте пользователям действительно необходимый доступ.
  • Для пользователей с правами администратора разумно настроить две учетные записи. Одна обычная учетная запись используется для электронной почты и других офисных задач, а вторая - для работы с повышенными привилегиями. С виртуальными машинами легче жить.
  • НЕ поощряйте регулярное использование общих учетных записей администратора / root, сложно отследить, кто и что делал.

Создание политик и процедур, позволяющих спокойно и эффективно справиться с ситуацией, когда кто-то попадает внутрь.

Политика событий безопасности обязательна для всех организаций. Это значительно сокращает фазу реакции «бегать с отсеченными головами», поскольку люди, как правило, становятся иррациональными, когда сталкиваются с такими событиями. Вторжения - большие и страшные дела. Стыд из-за вторжения может привести к тому, что уравновешенные системные администраторы начнут неправильно реагировать.

Все уровни организации должны быть осведомлены о политиках. Чем крупнее инцидент, тем больше вероятность того, что высшее руководство каким-то образом вмешается, и наличие установленных процедур для решения проблем значительно поможет отразить «помощь» свыше. Это также обеспечивает уровень прикрытия для технических специалистов, непосредственно участвующих в реагировании на инциденты, в виде процедур взаимодействия среднего менеджмента с остальной частью организации.

В идеале ваша политика аварийного восстановления уже определяет, как долго определенные службы могут быть недоступны до того, как сработает политика аварийного восстановления. Это поможет реагировать на инциденты, поскольку такие события являются бедствия. Если событие относится к типу, при котором окно восстановления НЕ будет выполнено (пример: сайт аварийного восстановления с горячим резервным копированием получает поток измененных данных в реальном времени, и злоумышленники удалили кучу данных, которые были реплицированы на сайт аварийного восстановления, прежде чем они были Следовательно, необходимо будет использовать процедуры восстановления после холода), тогда высшее руководство должно будет участвовать в переговорах по оценке рисков.

Некоторые компоненты любого плана реагирования на инциденты:

• Выявите скомпрометированные системы и открытые данные.
• С самого начала определите, нужно ли сохранять юридические доказательства для возможного судебного преследования.
  • Если доказательства должны быть сохранены не трогайте ничего об этой системе, если это абсолютно не требуется. Не авторизуйтесь в нем. Не просматривайте лог-файлы. Делать. Не. Коснитесь.
  • Если необходимо сохранить доказательства, скомпрометированные системы нужно оставить онлайн но отключен до тех пор, пока сертифицированный эксперт по компьютерной криминалистике не сможет проанализировать систему способом, совместимым с правилами обработки доказательств.
    • Выключение скомпрометированной системы может испортить данные.
    • Если ваша система хранения позволяет это (дискретное устройство SAN) сделать снимок затронутых LUN перед отключением и пометить их как доступные только для чтения.
  • Правила работы с доказательствами сложны, и их так легко испортить. Не делайте этого, если вы не прошли обучение на них. Большинство системных администраторов НЕ проходят такого обучения.
  • Если доказательства сохраняются, рассматривайте потерю услуги как катастрофа с потерей оборудования и начать процедуры восстановления с новым оборудованием.
• Заранее установленные правила о том, какие виды бедствий требуют уведомления. Законы и правила различаются в зависимости от местности.
  • Правила, касающиеся «разоблачения» и «доказанного компромисса», действительно различаются.
  • Правила уведомления потребуют участия отдела коммуникаций.
  • Если требуемое уведомление достаточно велико, необходимо будет привлечь руководство высшего уровня.
• Используя данные аварийного восстановления, определите, сколько времени «WTF только что произошло» можно потратить, прежде чем возврат службы в рабочее состояние станет более приоритетным.
  • Время восстановления обслуживания может потребовать работы по выяснению того, что случилось с подчиненным. Если это так, то сделайте образ диска затронутого устройства для анализа после восстановления услуг (это не доказательная копия, это для технических специалистов).
  • Планируйте свои задачи по восстановлению сервисов так, чтобы они включали в себя полную перестройку пораженной системы, а не просто устранение беспорядка.
  • В некоторых случаях время восстановления после обслуживания достаточно короткое, так что образы дисков необходимо делать сразу после обнаружения компрометации, и не следует сохранять юридические доказательства. После восстановления службы можно приступить к выяснению того, что произошло.
• Просмотрите файлы журналов, чтобы получить информацию о том, как злоумышленник проник и что он мог сделать однажды.
• Просмотрите измененные файлы, чтобы получить информацию о том, как они попали в систему и что они сделали после этого.
• Просмотрите журналы брандмауэра для получения информации о том, откуда они пришли, куда они могли отправить данные и сколько из них было отправлено.

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

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

Как правильные процедуры службы поддержки могут помочь

Нам нужно подумать о том, как здесь обращаются с клиентами (это касается как внутренних, так и внешних клиентов, обращающихся в службу поддержки).

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

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

1. Постарайтесь публиковать реалистичные обновления для клиентов и работать с ними, чтобы определить срочность возврата услуги в сеть. Важно знать потребности клиентов, но в то же время не позволяйте им навязывать вам невыполнимый график.
2. Убедитесь, что ваша группа поддержки знает, какая информация может и не может быть разглашена, и что они не должны поощрять слухи и домыслы (и абсолютно не должны обсуждать что-либо, что может нанести ущерб любым судебным действиям, которые ваша организация может предпринять или с которыми может столкнуться).
3. Одна положительная вещь, которую должна сделать служба поддержки, - это записывать все звонки, относящиеся к вторжению - это может помочь измерить нарушения, вызванные как самим вторжением, так и последующими процессами для борьбы с ним. Учет как временных, так и финансовых затрат на вторжение и смягчение последствий может быть очень полезным как при уточнении будущих стратегий, так и, очевидно, может оказаться полезным при любых юридических действиях. ITIL инцидент против записи проблемы Здесь может помочь - и само вторжение, и меры по устранению могут быть записаны как отдельные проблемы, и каждый вызывающий абонент отслеживается как инцидент одной или обеих проблем.

Как стандарты развертывания могут помочь

Развертывание в заданный шаблон (или, по крайней мере, контрольный список) тоже помогает, наряду с практикой контроля / управления изменениями любых настроек / обновлений вашего шаблона развертывания. У вас может быть несколько шаблонов для учета серверов, выполняющих разные задания (например, шаблон почтового сервера, шаблон веб-сервера и т. Д.).

Шаблон должен работать как для ОС, так и для приложений и включать не только безопасность, но и все настройки, которые вы используете, и в идеале должны быть написаны сценарием (например, шаблон), а не применяться вручную (например, контрольный список), чтобы максимально исключить человеческую ошибку.

Это помогает по-разному:

• Позволяет вам быстрее восстанавливать / перестраивать в случае вторжения (обратите внимание, что вы не должна развертывать из этого шаблона "как есть", потому что вы знать он уязвим, но позволяет вернуться к «последней удачной конфигурации» который необходимо подвергнуть дальнейшему укреплению перед развертыванием в реальном времени... и не забудьте обновить шаблон развертывания, если убедитесь, что он правильно заблокирован)
• Дает вам "основу" для сравнения взломанного сервера с
• Уменьшает количество ненужных ошибок, которые могут в первую очередь привести к вторжению
• Помогает с изменениями и управлением исправлениями, потому что, когда становится очевидным, что вам нужно исправление / обновление или процедурное изменение для безопасности (или по любым другим причинам в этом отношении), легче увидеть, какие системы нуждаются в изменении, упрощает написание тестов чтобы увидеть, правильно ли применено изменение и т. д.).
• Если все будет максимально последовательным и разумным, это поможет выделить необычные и подозрительные события.

Для большинства наших серверов мы полагаемся на брандмауэры хоста и сети, антивирусное / шпионское ПО, сетевую IDS и IDS хоста для большей части нашей профилактики. Это вместе со всеми общими рекомендациями, такими как минимальные привилегии, удаленные несущественные программы, обновления и т. Д. Отсюда мы используем такие продукты, как Nagios, Cacti и решение SIEM для различных базовых подкладок и уведомлений о том, когда происходят события. Наш HIDS (OSSEC) также выполняет много протоколирования типа SIEM, что приятно. Мы в основном стараемся блокировать как можно больше, но затем регистрируем централизованно, поэтому, если что-то все же произойдет, мы сможем проанализировать и сопоставить это.

То, что вы действительно хотите, можно разделить на 3 основные области:

1. Стандартная конфигурация системы
2. Мониторинг системы / приложений
3. Реагирование на инцидент

Если у вас есть какие-либо информационные (обеспечение | безопасность) сотрудников, вам обязательно стоит с ними поговорить. Хотя реагирование на инциденты часто является исключительной прерогативой указанного офиса, все остальное должно быть совместным усилием всех затронутых сторон.

Рискуя заниматься сутенерством, этот ответ на связанный вопрос должен проиндексировать для вас много полезных ресурсов: Советы по защите LAMP-сервера.

В идеале у вас должно быть наименьшее количество поддерживаемых операционных систем, и каждая из них должна быть создана с использованием базового образа. Вам следует отклоняться от базовой только настолько, насколько это требуется для предоставления любых услуг, которые предоставляет сервер. Отклонения должны быть задокументированы или могут потребоваться, если вы должны соответствовать PCI / HIPAA / и т. Д. или другие соответствия. В этом отношении может очень помочь использование систем управления развертыванием и конфигурацией. Специфика будет во многом зависеть от вашей ОС, cobbler / puppet / Altiris / DeployStudio / SCCM и т. Д.

Вы обязательно должны выполнять какой-то регулярный просмотр журнала. При наличии возможности SIEM может быть очень полезны, но у них есть и обратная сторона: они дороги как по закупочной цене, так и по затратам на строительство. Прочтите этот вопрос на сайте IT Security SE, чтобы получить комментарии по анализу журналов: Как вы проводите анализ журналов? Если это все еще слишком тяжело, даже обычные инструменты, такие как LogWatch, могут предоставить хороший контекст для того, что происходит. Однако важнее всего просто найти время, чтобы вообще посмотреть журналы. Это поможет вам познакомиться с нормальным поведением и распознать ненормальное.

Помимо просмотра журналов, также важен мониторинг состояния сервера. Очень важно знать, когда происходят изменения, запланированные или нет. Использование локального инструмента мониторинга, такого как Tripwire может предупредить администратора об изменениях. К сожалению, у SIEM и IDS есть обратная сторона: их дорого настраивать и / или покупать. Более того, без хорошей настройки ваши пороги предупреждений будут настолько высокими, что любые хорошие сообщения будут потеряны в шуме и станут бесполезными.

Правильный Информация о безопасности и управление событиями Действующая политика (SIEM) значительно облегчит вашу жизнь в сфере безопасности.

Я не специалист по безопасности, поэтому в основном доверяю им; но начиная с Принцип минимальных привилегий почти всегда значительно облегчает их работу. Применение этого как лечебной мази хорошо работает для многих аспектов безопасности: разрешений файлов, пользователей среды выполнения, правил брандмауэра и т. Д. ПОЦЕЛУЙ тоже никогда не болит.

Большая часть упомянутых здесь решений применима на уровне хоста и сети, но мы часто забываем о небезопасных веб-приложениях. Веб-приложения являются наиболее часто просматриваемой дырой в безопасности. Посредством веб-приложения злоумышленник может получить доступ к вашей базе данных или хосту. Никакой брандмауэр, IDS, брандмауэр не защитят вас от них. OWASP ведет список 10 самых критических уязвимостей и предлагает исправления для них.

http://www.scribd.com/doc/19982/OWASP-Web-Security-Guide