Обработка инцидентов информационной безопасности (Часть 2)

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

 

Превентивные мероприятия

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

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

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

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

Обнаружение и анализ инцидентов информационной безопасности

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

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

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

Признаки инцидента информационной безопасности

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

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

§ IDS сигнализируют о множественном повторяющемся событии

§ Анализ журнальных файлов автоматизированной системы даёт основание для вывода системным администраторам о возможности наступления события инцидента

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

§ IDS фиксирует переполнение буфера

§ уведомление антивирусной программы

§ крах WEB – интерфейса

§ пользователи сообщают о крайне низкой скорости при попытке выхода в Internet

§ системный администратор фиксирует наличие файлов с нечитабельными названиями

§ пользователи сообщают о наличие в своих почтовых ящиках множества повторяющихся сообщений

§ хост производит запись в журнал аудита об изменении конфигурации

§ приложение фиксирует в журнальном файле множественные неудачные попытки авторизации

§ администратор сети фиксирует резкое увеличение сетевого трафика, и.т.д.

Примерами событий, которые могут послужить источниками информационной безопасности могут служить:

§ журнальные файлы сервера фиксируют сканирование портов

§ объявление в СМИ о появлении нового вида эксплойта

§ открытое заявление компьютерных преступников об объявлении войны вашей организации и.т.д.

Анализ инцидентов информационной безопасности

Инцидент не является очевидным свершившимся фактом, напротив, злоумышленники стараются сделать всё чтобы не оставить в системе следов своей деятельности. Признаки инцидента содержит незначительное изменение в файле конфигурации сервера или, на первый взгляд, стандартная жалоба пользователя электронной почты. Принятие решения о наступлении события инцидента во многом зависит от компетентности экспертов команды реагирования. Необходимо отличать случайную ошибку оператора от злонамеренного целенаправленного воздействия на информационную систему. Факт отработки “в холостую” инцидента информационной безопасности также является инцидентом информационной безопасности, поскольку отвлекает экспертов команды реагирования от насущных проблем. Руководство организации должно обратить внимание на данное обстоятельство и предоставить экспертам команды реагирования известную свободу действий.

Составление диагностических матриц служит для визуализации результатов анализа событий, происходящих в информационной системе. Матрица формируется из строк потенциальных признаков инцидента и столбцов – типов инцидентов. В пересечении даётся оценка событию по шкале приоритетов “высокий”, “средний”, ”низкий”. Диагностическая матрица призвана документировать ход логических заключений экспертов в процессе принятия решения и, наряду с другими документами, служит свидетельством расследования инцидента.

Документирование инцидента информационной безопасности

Документирование событий инцидента информационной безопасности необходимо для сбора и последующей консолидации свидетельств расследования. Документированию подлежат все факты и доказательства злонамеренного воздействия. Различают технологические свидетельства и операционные свидетельства воздействия. К технологическим свидетельствам относят информацию, полученную от технических средств сбора и анализа данных (сниферы, IDS), к операционным – данные или улики, собранные в процессе опроса персонала, свидетельства обращений на service desk, звонки в call center.

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

§ текущий статус расследования

§ описание инцидента

§ действия, производимые командой реагирования в процессе обработки инцидента

§ список акторов расследования с описанием их функций и процентом занятости в процедуре расследования

§ перечень свидетельств (с обязательным указанием источников), собранных в ходе обработки инцидента

§ комментарии участников расследования инцидента

§ описание последующих действий и состояние процесса (ожидание ответа на запрос в call center, и.т.д.)

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

Приоритезация инцидентов информационной безопасности

Приоритезация инцидентов информационной безопасности базируется на следующих основных факторах:

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

§ Критичность вовлечённых в инцидент активов. Критичность активов обсуждалась на этапе подготовки к расследованию инцидентов.

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

Рассылка уведомлений об инциденте информационной безопасности

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

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

Литература

1. Материалы и публикации NIST: http://csrc.nist.gov/publications/nistpubs/index.html

2. BS 25999-1:2006 Управление непрерывностью бизнеса – Часть1: Практические правила

3. BS ISO/IEC 27001:2005 Информационные технологии. Методы обеспечения безопасности. Системы управления информационной безопасностью. Требования

4. ISO13335-1:2004Информационные технологии. Руководство по управлению ИТ безопасностью. Концепции и модели для управления безопасностью информационных и телекоммуникационных технологии)