Политики безопасности компании при работе в Интернет - Сергей Петренко

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

Другая важная функция точки контакта – поддержание связей с правоохранительными органами и другими внешними организациями, когда возникает нужда в согласованных действиях нескольких инстанций.

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

Регистрационная документация

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

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

• все системные события (приобщите к документации системный регистрационный журнал);

• все ваши действия (с указанием времени);

• все телефонные переговоры (имя собеседника, дата, время и содержание разговора).

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

Обзор

После ликвидации нарушения режима информационной безопасности необходимо предпринять ряд действий, а именно:

• произвести переучет системных активов, то есть тщательно проверить, как инцидент повлиял на состояние систем;

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

• произвести новый анализ риска с учетом информации, полученной вследствие инцидента;

• должно быть начато следствие против виновников инцидента, если это признано необходимым.

Перечисленные шаги направлены на обеспечение комитета по политике безопасности предприятия обратной связью, чтобы политика оперативно пересматривалась и подправлялась.

Устранение слабостей

Устранить все слабости, сделавшие возможным нарушение режима безопасности, весьма непросто. Ключевым моментом здесь является понимание механизма вторжения. В некоторых случаях разумно как можно быстрее отключить доступ ко всей системе или к некоторым из ее функциональных возможностей, а затем поэтапно возвращать ее в нормальное состояние. Учтите, что полное отключение доступа во время инцидента заметят все пользователи, в том числе и предполагаемые виновники; системные администраторы должны помнить об этом. Естественно, ранняя огласка может помешать следствию. Однако продолжение инцидента порой чревато увеличением ущерба, усугублением ситуации или даже привлечением к административной или уголовной ответственности.

Если установлено, что вторжение стало возможным вследствие дефектов аппаратного или программного обеспечения, следует как можно быстрее уведомить производителя (или поставщика), а также группу реагирования CERT. Настоятельно рекомендуется включить в текст политики безопасности соответствующие телефонные (факсовые) номера, а также адреса электронной почты. Чтобы можно было оперативно уяснить суть проблемы, дефект нужно описать максимально детально (включая информацию о его использовании нарушителем).

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

Извлекайте уроки из инцидента и всегда корректируйте политику и процедуры безопасности, чтобы отразить изменения, необходимость которых выявил инцидент.

Оценивая ущерб. Прежде чем начинать восстановительные работы, необходимо уяснить истинные размеры ущерба. Возможно, на это уйдет много времени, но зато появится понимание природы инцидента и будет заложена база для проведения расследования. Лучше всего сравнивать текущее состояние с резервными копиями или с лентами, полученными от поставщика; еще раз напомним: предварительная подготовка – ключевой элемент восстановления. Если система поддерживает централизованное ведение регистрационного журнала (как правило, так и бывает), перемещайтесь по журналу назад и отмечайте аномалии.

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

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

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

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

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