Управление инцидентами напрямую
влияет на непрерывность бизнес-процессов в компании. Этот процесс отвечает за
возврат системы информационной безопасности в ее изначальное (до инцидентное)
состояние. Управление инцидентами описано во многих международных стандартах, а
организации работы этого процесса, уделено достаточно много материала. Я попробовал кратко описать процесс управления инцидентами, и изложил его здесь.
Основными документами,
где описан процесс управления инцидентами, являются:
1.
NIST 800-61. Computer Security
Incident Handling Guide;
2. ГОСТ Р ИСО/МЭК 18044-2007.
Информационная технология. Методы и средства обеспечения безопасности. Менеджмент
инцидентов информационной безопасности.
Принцип управления
инцидентами, как и любой процесс, обязан удовлетворять требованиях Деминга, т.е. находиться в состоянии
постоянного совершенствования.
Скорость реакции на инцидент,
является основным параметром, который регулирует построение системы управления
инцидентами. Для построения такой системы необходимо разработать правила регламентирующие
шаги для решения инцидента. Должны быть классифицированы все возможные
инциденты в зависимости от угроз, описанных в «Модели угроз».
Хорошим помощником при
построении системы управления инцидентами является система сбора и анализа всей
информации поступающей от всех сетевых устройств. К таким устройствам
обязательно должны быть отнесены: системы обнаружения и предотвращения
вторжений, антивирусного программное обеспечение, системы разграничения доступа,
в том числе и СКУД, а также критическое для существования субъекта программное
обеспечение. Такая система не только должна уметь собирать данные со всех устройств,
но она должна сравнивать эти данные между собой, находить
коллизии, формировать отчеты о состоянии системы информационной
безопасности.
1-этап. Подготовка.
К первому этапу должны
уже быть разработаны следующие документы: политика информационной безопасности,
модель угроз, сформированы списки активов субъекта и лиц, отвечающих за ведение
этих активов. Технические средства, входящие в систему информационной
безопасности уже сконфигурированы и задокументированы.
На этом этапе формируется
группа по управлению инцидентами, составляются планы работы этой группы, планы
обучения, происходит классификация возможных инцидентов, разделение их на
группы и классы, а также согласовываются схемы взаимодействия:
· С охранными предприятиями;
· Аварийными службами;
· Правоохранительными органами;
· С партнерами и потребителями услуг и
т.д.
Если группа по
реагированию на инциденты входит в Service Desk компании, тогда необходимо:
a) договориться о терминологии, что бы все
разговаривали на одном языке. Определить что такое «инцидент ИБ» и что такое
«инцидент ИТ»;
b) структурировать и классифицировать
инциденты информационной безопасности;
c) Назначить ответственных за управление
инцидентами в области информационной безопасности.
Группа реагирования на
инциденты ИБ подготавливает свою библиотеку документов. Данная библиотека, содержит
операционные документы, касающиеся работы технических средств, регламенты
обслуживания, а также способы связи с группой реагирования. Разрабатываются
различные формы отчетов (Примеры форм отчетов есть в ГОСТ Р ИСО/МЭК
18044-2007).
Для классификации
инцидентов информационной безопасности создается отдельная рабочая группа, куда
входят представители владельца актива, сотрудники службы информационной безопасности,
сотрудники отдела информационных технологий.
Для классификации
инцидентов могу применяться следующие параметры:
1. По атакам на ресурсы;
2. По серьезности произошедшего
инцидента;
3. По характеристикам их возникновения.
Первый этап, является
самой трудоемким и сложным, от того как вы подойдете к решению поставленных
задач, зависит непрерывность бизнеса и авторитет службы информационной
безопасности.
2-этап. Обнаружение.
Инцидент информационной
безопасности может быть обнаружен техническими средствами или человеческими
ресурсами. При обнаружении инцидента происходит его категорирование.
Категорирование может осуществлять лицо обнаружившее инцидент, диспетчер или
специалист группы реагирования. На мой взгляд правильным является ситуация,
когда категорированием занимается обученный человек, к которому стекается вся
информация обо всех не штатных ситуациях. В данном случае, человеком который
производит категорирование инцидента, является диспетчер.
Для второго этапа главным
параметров является скорость реагирования на инцидент информационной
безопасности. Для этого на первом этапе была произведена классификация угроз
информационной безопасности, в зависимости от угрозы определено время на
реакцию и время на устранение инцидента. Матрица реагирования представлена в
таблице.
|
Номер
инцидента
|
приоритет
|
Время жизни инцидента
|
|
|
начало реагирования
|
Инцидент искоренен
|
||
|
1
|
катастрофа
|
Через 0,5 рабочих часа
|
Через 4 рабочих часа
|
|
15
|
высокий
|
Через 1 рабочий час
|
Через 2 рабочих дня
|
Пример: Под номерами 1 и
15 мы подразумеваем отказ в обслуживании сетевого сегмента и заражение
компьютеров вирусом.
После того как вы
обнаружили инцидент ИБ, необходимо начать его расследование с целью получения
доказательства его происшествия. Самостоятельно собранные доказательства в суде
РФ не принимаются. Можно обратиться в
три органа за помощью в получении доказательства:
1. В следственный комитет РФ;
2. В прокуратору;
3. В МВД РФ;
Для фиксации инцидента, проводится
анализ изменённых файлов журнала, информации, конфигурационных файлов. Анализ
измененных файлов выполняются специальными программными комплексами. Они
анализируют файловую систему, информацию, размещенную на диске. Следует
обратить внимание на тот факт, что надо применять такие программы, которые не
изменяют атрибуты анализируемой информации, это необходимо, чтобы анализируемая
система оставалась в неизменном виде. Вторым этапом является документирование
произошедшего инцидента, т.е. создаётся карточка инцидента, в которой
указывается:
1. Кто и когда зафиксировал инцидент;
2. На каком объекте, и на каком
оборудовании он произошел;
3. Насколько критичен объект
4. Создаются связи между карточкой
инцидента и log-файлами журналов IDS/IPS, МЭ и т.д.;
5. Определяются последствия инцидента.
3-этап. Искоренение.
Когда собраны все
доказательства нарушения информационной безопасности, происходит искоренение
инцидента, согласно разработанной методике. Ликвидация инцидента как правило
происходит на третьем этапе, однако не исключения ситуация, когда последствия
негативного воздействия искореняются уже на втором этапе. В этом случае следует
убедиться, что во время работы над инцидентом, вы не уничтожите улики.
При искоренении инцидента
важно быстро и надежно изолировать атакованную систему от всех других
взаимосвязанных систем и элементов.
4-й этап. Восстановление.
Во время восстановления
работоспособности системы, могут быть инициированы следующие процессы:
· Процесс управления изменениями;
· Процесс управление конфигурации.
В этом случае включается в процесс
управления инцидентами отдел информационных технологий. Именно поэтому на
первом этапе необходимо детально проработать процессы взаимодействия между
всеми структурными подразделениями.
5-этап. Анализ.
При анализе инцидента
используются материалы, полученные на предыдущих этапах управления инцидентами.
В конце анализа
составляется отчет об инциденте, который обязан содержать правдивую и точную
информацию о:
1. Скорость обнаружения инцидента.
2. Принятые меры и их эффективность.
3. Состояние системы до и после
инцидента. Какие компоненты были изменены.
4. Прямые и косвенные затраты на решение
инцидента
5. Причины возникновения инцидента
6. Рекомендации по недопущению такой
ситуации в дальнейшем
Настоящий отчет должен
быть отправлен лицам, определенным в вашей политики информационной
безопасности. Это могут быть как топ менеджеры, так и простые аналитики.
После того как вы
составите отчет об инциденте необходимо заново провести его классификацию, что
бы точно определить правильность первоначальной классификации. Это связано с тем, что при первой
классификации, Вы не обладаете полнотой системных данных о произошедшем
инциденте. Вы видите точку, которая произвела дисбаланс в вашей системе, но не
видите её связи с другими элементами.
Важно: Произошедший инцидент информационной безопасности, является поводом для
пересмотра всей политики информационной
безопасности.
Важно: Каждый инцидент необходимо заносить в базу знаний инцидентов.
Комментариев нет:
Отправить комментарий