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

Британский стандарт BS 25999-1:2006 Управление непрерывностью бизнеса – Часть1: Практические правила даёт следующее определение термина “управление непрерывностью бизнеса” – процесс управления, в ходе реализации которого выявляются потенциальные угрозы деятельности организации, оцениваются возможные последствия для бизнес – операций в случае реализации данных угроз, а также создаётся базис для обеспечения способности организации восстанавливать свою деятельность и эффективно реагировать на инциденты, что даёт необходимую гарантию соблюдения интересов сторон, занятых в совместной бизнес – деятельности, гарантии сохранения репутации, бренда и деятельности по созданию добавленной стоимости.

Принципы реализации

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

В соответствии с лучшими мировыми практиками сформулируем некоторые принципы, соблюдая которые организация обеспечит эффективную политику реагирования на инциденты информационной безопасности:

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

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

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

• превентивные меры (предотвращение проблем до наступления события инцидента) являются менее дорогостоящими, чем работы по ликвидации последствий инцидентов, следовательно, превентивные меры являются неотъемлемой частью политики реагирования на инциденты информационной безопасности
• процедура реагирования на инциденты и расследование по факту их происшествия будет более эффективной, если определённым видам информационных ресурсов будут поставлены в соответствие адекватные средства технической защиты информации

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

• в процессе расследования инцидента организации, возможно, потребуется общаться со сторонними организациями с целью детального расследования и доведения процедуры расследования до логичного завершения (СМИ, органы правопорядка, пострадавшие со стороны третьих лиц)
• в случае несоразмерного разглашения конфиденциальной информации, связанной с результатами расследования инцидента, ущерб от подобных действий может быть соизмерим или превышать ущерб, нанесённый вследствие самого инцидента информационной безопасности
• урегулированию проблемы несоразмерного разглашения служит создание, так называемых, контактных позиций (POC – point of contact), структура и правомочность которых оговаривается на этапе формирования политики расследования инцидентов и представляет собой юридически закреплённую доверительную среду участников информационного обмена

Информирование о результатах расследования инцидента своих сотрудников и партнёров.

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

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

Формализация принципов приоритезации событий информационной безопасности.

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

• действия команды по расследованию инцидентов должны быть формализованы и представлены в виде Соглашения об уровне обслуживания (SLA – Service Level Agreement), где подробно определяются действия каждого сотрудника и время реакции на определённые события

Анализ инцидентов и обработка результатов с целью получения практического опыта:

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

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

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

• понимание руководством организации необходимости реагирования на инциденты информационной безопасности
• управление процедурой расследования инцидентов информационной безопасности
• определение целей и места политики расследования инцидентов в общей структуре процессов управления безопасностью и организацией в целом (политика расследования инцидентов является частью процесса обеспечения непрерывности функционирования организации)
• определение понятий “инцидент информационной безопасности” и “последствия инцидента информационной безопасности” в контексте сферы деятельности организации
• описание состава, структуры, функциональных обязанностей, зон ответственности, ролей, правил внутриорганизационного взаимодействия, порядка внешних сношений команды по расследованию инцидентов информационной безопасности
• порядок установления приоритетов инцидентов и оценки серьёзности последствий инцидентов информационной безопасности
• оценка критериев качества работы команды по расследованию инцидентов
• разработка форм отчётности и регламента оповещений об инциденте
• разработка набора процедур, описывающих действие сотрудников организации в случае инцидента информационной безопасности (выделенный телефон, адрес электронной почты)
• разработка стандартных операционных процедур (SOPs – Standard Operating Procedures), подробно описывающих действия сотрудников команды реагирования в процессе обработки инцидента информационной безопасности
• порядок пересмотра, тестирования и актуализации стандартных операционных процедур

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

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

Существуют три основных типа моделей структуры команды реагирования:

• централизованная модель – реализована в виде единственной на всю организацию структуры, состоящей из трёх линий поддержки: call center (телефон горячей линии), специалисты технической поддержки (управление средствами сбора и анализа данных), группа расследования (аналитическая служба). Данная модель применима к небольшим организациям, в которых отсутствует географически распределённая сеть филиалов
• распределённая модель – реализована на основе централизованной модели управления. Отличие данной модели от централизованной заключается в наличие дочерних структур в крупных филиалах организации или удалённых вычислительных центрах. В данном случае структура команды реагирования головного офиса дополняется службой координации и централизованного хранения данных об инцидентах информационной безопасности
• корпоративная модель – реализована по принципу центра компетенции. Координационный совет по вопросам реагирования на инциденты информационной безопасности обрабатывает консолидированную информацию от юридических лиц, входящих в корпорацию, и координирует действия дочерних структур

Существуют три основные модели комплектации структуры команды реагирования персоналом:

• организация выполняет всю работу, связанную с обработкой инцидента самостоятельно, силами собственного персонала
• в состав команды расследования инцидентов привлекаются сотрудники профилирующих фирм. Данная модель внедряется в организациях, которые обеспечивают доступность своих ресурсов по схеме 24/7. В данном случае возможен вариант, когда реагирование и первичную обработку берёт на себя фирма, предоставляющая услуги аутсорсинга, а расследование инцидента внутри организации – местная команда реагирования
• процедура реагирования и обработки инцидентов полностью передаётся на обслуживание профилирующей фирме. Данная модель хорошо подходит организациям, которые в силу объективных причин не могут заниматься обработкой инцидентов, но нуждаются в подобном функционале

Факторы, влияющие на выбор модели:

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

Факторы, влияющие на выбор модели в случае привлечения стороннего обслуживания:

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

Взаимодействие со структурой организации

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

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

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

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

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

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

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

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

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

Этап подготовки к расследованию инцидентов заключается в сборе и анализе информации об инцидентах информационной безопасности, обучении персонала и подготовки необходимого инструментария для реагирования и расследования инцидента:

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

В состав инструментария должны входить, также, средства программного обеспечения и аппаратные средства сбора данных:

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

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

• просмотру состояния портов операционной среды
• свидетельству работы операционных систем, приложений, протоколов, систем обнаружения вторжений, сигнатур антивирусов
• просмотру статистических журналов работы сети наиболее критичных устройств (WEB – серверы, серверы электронной почты, протоколы работы FTP – серверов)
• просмотру журналов активности приложений
• журналам криптографических средств
• операционным системам, для анализа журнальных файлов, в том числе, с правами администратора
• данным об загружаемых обновлениях в операционных средах
• информации о регламентах резервного копирования и тестировании резервных носителей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стратегия противодействия распространению последствий инцидента

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

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

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

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

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

Сбор свидетельств инцидента и их обработка

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

• идентификация источника (местоположение, ID, имя хоста, MAC – address, IP – address, и.т.д.)
• персональные данные сотрудников, обращавшихся за помощью
• дата и время каждого свидетельства
• местоположение ресурса хранения свидетельства

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

Идентификация нарушителя

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

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

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

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

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

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

Типичными метриками для хранения данных инцидента являются:

• количество обработанных инцидентов информационной безопасности
• среднее время, затрачиваемое на обработку одного инцидента
• описание расследования инцидента, включая рассмотренные источники данных инцидента, свидетельства инцидента, качественная или количественная оценка ущерба, причина возникновения события инцидента, события, которые могли бы предотвратить инцидент
• субъективная оценка инцидента – качественная оценка действий команды реагирования, включая практическое применение политики расследования инцидентов, использование инструментария и ресурсов, использование внутренней документации, качество обучения на этапе подготовки

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

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

• возможные разбирательства в суде
• время хранения свидетельств
• стоимость хранения (стоимость эксплуатации носителей и систем)

Контрольные листы мероприятий при проведении расследования инцидента информационной безопасности

В процессе расследования инцидента, хорошей практикой является ведение контрольных листов наблюдений (check lists), с целью управления процессом расследования. Данная практика хорошо применима в средних и крупных организациях, где количество одновременно расследуемых инцидентов может превышать десяток единиц. Структура контрольного листа может быть произвольной и разрабатываться экспертами команды реагирования с учётом особенности проводимых в организации мероприятий по расследованию инцидентов.

Литература

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 Информационные технологии. Руководство по управлению ИТ безопасностью. Концепции и модели для управления безопасностью информационных и телекоммуникационных технологии)

Сергей Романовский, rom_se@amt.ru