close

Вход

Забыли?

вход по аккаунту

?

1997.«Управление инцидентами кибербезопасности»

код для вставкиСкачать
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ
Федеральное государственное бюджетное
образовательное учреждение
высшего профессионального образования
«ПЕНЗЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
С. Л. ЗЕФИРОВ, А. Ю. ЩЕРБАКОВА
УПРАВЛЕНИЕ ИНЦИДЕНТАМИ
КИБЕРБЕЗОПАСНОСТИ
УЧЕБНОЕ ПОСОБИЕ
ПЕНЗА 2012
0
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ
Федеральное государственное бюджетное
образовательное учреждение
высшего профессионального образования
«Пензенский государственный университет» (ПГУ)
С. Л. Зефиров, А. Ю. Щербакова
Управление инцидентами
кибербезопасности
Учебное пособие
Пенза
Издательство ПГУ
2012
1
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
УДК 004.056
З-47
Рецензенты:
кандидат технических наук, доцент,
член-корреспондент Академии криптографии РФ,
научный директор НПФ «Кристалл»
В. В. Андрианов;
председатель НТС филиала «Аргус»
ОАО «Пензенский научно-исследовательский
электротехнический институт»
В. В. Коляда
З-47
Зефиров, С. Л.
Управление инцидентами кибербезопасности : учеб. пособие / C. Л. Зефиров, А. Ю. Щербакова. – Пенза : Изд-во
ПГУ, 2012. – 104 с.
ISBN 978-5-94170-559-7
Рассматриваются процессы и процедуры управления инцидентами
информационной безопасности информационно-телекоммуникационной
системы организации и управления инцидентами кибербезопасности:
неавторизованный доступ, отказ в обслуживании, внедрение вредоносного кода, сбор информации. Учебное пособие разработано на основе источников, отражающих лучшие мировые и отечественные практики.
Подготовлено на кафедре «Информационная безопасность систем и
технологий» и предназначено для студентов специальностей 090302 «Информационная безопасность телекоммуникационных систем» и 090303
«Информационная безопасность автоматизированных систем», изучающих вопросы управления инцидентами кибербезопасности в дисциплинах «Управление информационной безопасностью телекоммуникационных систем», «Менеджмент инцидентов информационной безопасности
защищенных телекоммуникационных систем», «Управление информационной безопасностью», «Менеджмент инцидентов информационной
безопасности защищенных автоматизированных систем управления».
УДК 004.056
© Пензенский государственный
университет, 2012
ISBN 978-5-94170-559-7
2
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
СОДЕРЖАНИЕ
Введение....................................................................................................................6
1. Система управления инцидентами кибербезопасности ...................................8
1.1. Инциденты кибербезопасности. Процессы управления инцидентами.....8
1.2. Планирование системы управления инцидентами
информационной безопасности ............................................................................ 10
1.2.1. Формирование политики управления инцидентами
информационной безопасности ............................................................................ 10
1.2.2. Формирование процедур управления инцидентами
информационной безопасности ............................................................................ 11
1.2.3. Создание группы реагирования на инциденты
информационной безопасности ............................................................................ 12
1.2.4. Подготовка к обработке инцидентов.................................................... 13
1.2.5. Формирование последовательности действий
при обработке инцидентов .................................................................................... 13
1.2.6. Классификация инцидентов по значимости ........................................ 16
1.2.7. Обеспечение осведомленности и обучение управлению
инцидентами .......................................................................................................... 17
1.3. Использование системы управления инцидентами
информационной безопасности ............................................................................ 18
1.3.1. Последовательность действий при обработке инцидента.................. 18
1.3.2. Обнаружение и анализ инцидента........................................................ 19
1.3.3. Реагирование на инциденты.................................................................. 23
1.4. Анализ обработки инцидентов.................................................................... 26
1.4.1. Изучение полученного опыта ............................................................... 26
1.4.2. Определение улучшения безопасности................................................ 27
1.4.3. Определение улучшения системы управления инцидентами............ 27
1.5. Улучшение системы управления инцидентами ........................................ 28
1.5.1. Улучшение оценки рисков и управления информационной
безопасностью ........................................................................................................ 28
1.5.2. Улучшение безопасности ...................................................................... 28
1.5.3. Улучшение системы управления инцидентами .................................. 28
Контрольные вопросы............................................................................................ 28
2. Управление инцидентами неавторизованного доступа.................................. 30
2.1. Определение инцидента неавторизованного доступа.
Цели инцидента неавторизованного доступа ...................................................... 30
2.2. Планирование системы управления инцидентами
неавторизованного доступа................................................................................... 30
2.2.1. Подготовка к обработке инцидента...................................................... 30
2.2.2. Выбор защитных мер ............................................................................. 34
3
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
2.2.3. Формирование последовательности действий при обработке
инцидентов неавторизованного доступа ..............................................................36
2.2.4. Формирование порядка обработки инцидента
неавторизованного доступа ...................................................................................37
2.3. Использование системы управления инцидентами
неавторизованного доступа ...................................................................................38
2.3.1. Обнаружение и анализ инцидента неавторизованного доступа ........38
2.3.2. Сдерживание инцидента неавторизованного доступа ........................43
2.3.3. Устранение инцидента неавторизованного доступа
и восстановление после него .................................................................................45
2.3.4. Сбор и обработка свидетельств инцидента
неавторизованного доступа ...................................................................................46
Контрольные вопросы ............................................................................................46
3. Управление инцидентами отказа в обслуживании..........................................47
3.1. Определение инцидента отказа в обслуживании. Примеры
инцидентов отказа в обслуживании......................................................................47
3.2. Планирование системы управления инцидентами отказа
в обслуживании.......................................................................................................51
3.2.1. Подготовка к обработке инцидента .......................................................51
3.2.2. Выбор защитных мер...............................................................................54
3.2.3. Формирование последовательности действий при обработке
инцидентов отказа в обслуживании......................................................................55
3.2.4. Формирование порядка обработки инцидента отказа
в обслуживании.......................................................................................................57
3.3. Использование системы управления инцидентами отказа
в обслуживании.......................................................................................................57
3.3.1. Обнаружение и анализ инцидента отказа в обслуживании.................57
3.3.2. Сдерживание, устранение инцидента отказа в обслуживании
и восстановление после него .................................................................................61
3.3.3. Сбор и обработка свидетельств инцидента отказа
в обслуживании.......................................................................................................62
Контрольные вопросы ............................................................................................62
4. Управление инцидентами внедрения вредоносного кода ..............................63
4.1. Определение инцидента внедрения вредоносного кода.
Примеры атак, связанных с внедрением вредоносного кода .............................63
4.2. Планирование системы управления инцидентами внедрения
вредоносного кода ..................................................................................................66
4.2.1. Подготовка к обработке инцидента .......................................................66
4.2.2. Выбор защитных мер...............................................................................71
4.2.3. Формирование последовательности действий при обработке
инцидентов внедрения вредоносного кода ..........................................................72
4
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
4.2.4. Формирование порядка обработки инцидента внедрения
вредоносного кода.................................................................................................. 74
4.3. Использование системы управления инцидентами внедрения
вредоносного кода.................................................................................................. 75
4.3.1. Обнаружение и анализ инцидента внедрения вредоносного
кода .......................................................................................................................... 75
4.3.2. Сдерживание и устранение инцидента внедрения
вредоносного кода.................................................................................................. 81
4.3.3. Восстановление после инцидента внедрения вредоносного
кода .......................................................................................................................... 84
4.3.4. Сбор и обработка свидетельств инцидента внедрения
вредоносного кода.................................................................................................. 85
Контрольные вопросы............................................................................................ 85
5. Управление инцидентами сбора информации................................................. 86
5.1. Определение инцидента сбора информации. Цели инцидента сбора
информации ............................................................................................................ 86
5.2. Планирование системы управления инцидентами сбора информации ... 86
5.2.1. Подготовка к обработке инцидента....................................................... 86
5.2.2. Выбор защитных мер .............................................................................. 89
5.2.3. Формирование последовательности действий при обработке
инцидентов сбора информации............................................................................. 91
5.2.4. Формирование порядка обработки инцидента сбора информации.... 93
5.3. Использование системы управления инцидентами сбора инфрмации.... 93
5.3.1. Обнаружение и анализ инцидента сбора информации........................ 93
5.3.2. Сдерживание инцидента сбора информации........................................ 96
5.3.3. Устранение инцидента и восстановление после инцидента
сбора информации
97
5.3.4. Сбор и обработка свидетельств инцидента
сбора информации.................................................................................................. 97
Контрольные вопросы............................................................................................ 97
Заключение.............................................................................................................. 99
Библиографический список................................................................................. 100
Приложение. Сценарии инцидента..................................................................... 101
5
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Введение
Государственные и межгосударственные информационно-телекоммуникационные системы, сети общего пользования, трансграничные каналы передачи информации, в которых создается, перемещается и потребляется информация, образуют в совокупности мировое
информационное пространство (киберпространство). Киберпространство для многих стран становится неотъемлемой частью управления
экономикой и национальной безопасностью, для людей – средством
общения, источником знаний. Киберпространство все больше внедряется в сферы деятельности человека, общества. С одной стороны,
появляются новые возможности для деятельности человека, общества. С другой стороны, эта положительная тенденция сопровождается
ростом преступности в глобальном информационном пространстве:
кража активов, вывод из строя и нарушение функционирования систем, негативное информационное воздействие и т.д.
В России проблема преступности в киберпространстве (киберпреступности) носит актуальный характер, так как стремительное
развитие информатизации в России несет в себе потенциальную возможность использования информационных и телекоммуникационных
технологий в корыстных и других интересах, что в известной мере
ставит под угрозу национальную и экономическую безопасность государства.
Проблемы борьбы с киберпреступностью должны решаться в
правовой и технической области. Технические проблемы, возникающие в результате злоумышленной активности в глобальном информационном пространстве, – это сфера деятельности специалистов по
информационной безопасности. В связи с возрастающим влиянием
киберпространства на жизнедеятельность общества повышается значимость безопасности в киберпространстве (кибербезопасности) в
областях обеспечения информационной безопасности.
Рекомендация МСЭ-T X.1205 Overview of Cibersecurity определяет кибербезопасность как набор средств, стратегии, принципы
обеспечения безопасности, гарантии безопасности, руководящие
принципы, подходы к управлению рисками, действия, профессиональную подготовку, практический опыт, страхование и технологии,
которые могут быть использованы для защиты киберсреды, ресурсов
организации и пользователя. Ресурсы организации и пользователя
включают подсоединенные компьютерные устройства, персонал, инфраструктуру, приложения, услуги, системы электросвязи и всю со6
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
вокупность переданной и/или сохраненной информации в киберсреде. Обеспечение кибербезопасности состоит в попытке достижения
и сохранения свойств безопасности активов организации или пользователя, направленных против соответствующих угроз безопасности в киберсреде. Общие задачи кибербезопасности включают обеспечение доступности, целостности и конфиденциальности защищаемых активов.
Одним из важнейших аспектов при обеспечении кибербезопасности в реальном времени является управление (менеджмент) инцидентами кибербезопасности, включая стратегический и тактический
анализ кибератак, своевременное и адекватное реагирование, оценку
уязвимостей, применение планов непрерывности обеспечения информационной безопасности, совместное использование информации об инцидентах заинтересованными организациями.
В данном учебном пособии рассматривается система управления инцидентами кибербезопасности как часть системы управления
инцидентами информационной безопасности. В связи с этим в работе представлен общий подход к управлению (менеджменту) инцидентами ИБ и описывается управление инцидентами кибербезопасности, связанными с атаками из внешних по отношению к объекту
информационных сред глобального киберпространства. В работе не
рассматривается управление инцидентами, связанными с действиями персонала объекта, со злоумышленными действиями инсайдера,
когда в основном преобладают проблемы организационных мер защиты.
В разделе 1 рассматривается построение системы управления
инцидентами информационной безопасности на основе лучших мировых и отечественных практик по обеспечению информационной
безопасности. Разделы 2–5 посвящены планированию и использованию системы управления инцидентами для обработки инцидентов
кибербезопасности: неавторизованный доступ, отказ в обслуживании, вредоносный код, сбор информации.
7
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
1. Система управления
инцидентами кибербезопасности
1.1. Инциденты кибербезопасности.
Процессы управления инцидентами
Инцидент кибербезопасности представляет собой одно или серию нежелательных событий информационной безопасности (ИБ),
связанных с атаками из внешних по отношению к объекту информационных сред глобального киберпространства, которые имеют значительную вероятность компрометации бизнес-операций и угрожают кибербезопасности. Инциденты кибербезопасности неизбежно
будут происходить в информационно-телекоммуникационных системах (ИТКС) объектов ввиду высокой изменчивости и неопределенности глобального информационного пространства, частью которого они являются, и появления новых уязвимостей ИТКС вследствие изменения внутренней информационной среды объекта.
К инцидентам кибербезопасности относятся [1]:
– неавторизованный доступ;
– отказ в обслуживании;
– вредоносный код;
– сбор информации.
Важнейшей частью общей стратегии обеспечения ИБ организации является структурированный подход к управлению инцидентами ИБ, в том числе к управлению инцидентами кибербезопасности.
Целями такого подхода является построение системы управления
инцидентами ИБ, в рамках которой реализуется система управления
инцидентами кибербезопасности. Система управления инцидентами
ИБ (в том числе инцидентами кибербезопасности) должна обеспечить следующее:
– события ИБ должны быть обнаружены и эффективно обработаны, в частности, определены как относящиеся или не относящиеся
к инцидентам ИБ;
– идентифицированные инциденты ИБ должны быть оценены, и
реагирование на них должно быть осуществлено наиболее целесообразным и результативным способом;
– негативные воздействия инцидентов ИБ на организацию и ее
бизнес-операции необходимо минимизировать соответствующими
8
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
защитными мерами, являющимися частью процесса реагирования
на инцидент;
– из инцидентов ИБ и управления ими необходимо извлечь уроки. Это увеличивает шансы предотвращения инцидентов ИБ в будущем, улучшение использования защитных мер, улучшение системы управления инцидентами ИБ [2].
Для достижения указанных целей система управления инцидентами ИБ должна включать четыре процесса (этапа обработки инцидентов):
– планирование и подготовка;
– использование;
– анализ;
– улучшение.
Содержание этих процессов показано на рис. 1.
Рис. 1. Система управления инцидентами
информационной безопасности
9
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
1.2. Планирование системы управления
инцидентами информационной безопасности
1.2.1. Формирование политики управления
инцидентами информационной безопасности
Политика управления инцидентами ИБ предназначена для персонала, имеющего авторизованный доступ к информационным системам организации и местам их расположения.
Основные вопросы, которые должна включать политика управления инцидентами ИБ, таковы:
– обзор процедур обнаружения событий, оповещения (информирования) и сбора соответствующей информации ИБ, и как эта
информация должна использоваться для определения инцидентов
ИБ. Этот обзор должен содержать перечень возможных событий
ИБ, а также информацию о том, как оповещать о них, что сообщать, когда и кому, а также как обращаться с новыми событиями ИБ;
– обзор процесса оценки инцидентов ИБ, включая перечень ролей, и дальнейшие действия;
– краткое изложение действий после подтверждения того, что событие ИБ является инцидентом ИБ. Эти действия могут быть такими:
а) немедленное реагирование;
б) оповещение (информирование) соответствующего персонала
или третьих сторон;
в) установление факта нахождения инцидента ИБ под контролем;
г) дальнейшее реагирование;
д) объявление «кризисной ситуации»;
е) обеспечение безопасного хранения свидетельств в электронном виде на случай судебного разбирательства или внутреннего
дисциплинарного расследования;
ж) действия после разрешения инцидента ИБ, включая извлечение уроков и улучшение управления инцидентами ИБ;
з) описание деятельности группы реагирования на инциденты
ИБ (ГРИИБ), включающее следующие вопросы:
и) организационная структура ГРИИБ и основные роли персонала ГРИИБ;
10
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
к) цели, сфера деятельности и полномочия ГРИИБ;
л) связь со сторонними организациями;
м) требования к программам обеспечения осведомленности и обучения управлению инцидентами ИБ.
1.2.2. Формирование процедур управления
инцидентами информационной безопасности
Для создания системы управления инцидентами ИБ должны
быть разработаны детальные процедуры для всех этапов управления
инцидентами ИБ.
Для этапа «Планирование и подготовка» должны быть сформированы процедуры:
– подготовки к обработке инцидента ИБ;
– формирования последовательности действий при обработке
инцидентов ИБ;
– классификации инцидентов ИБ по значимости.
Для этапа «Использование» должны быть сформированы процедуры:
– обнаружения и анализа инцидента ИБ;
– сдерживания инцидента ИБ;
– устранения инцидента ИБ и восстановления после инцидента;
– сбора доказательств об инциденте ИБ.
Для этапа «Анализ» должны быть сформированы процедуры:
– идентификации и документального оформления опыта, извлеченного из инцидентов ИБ;
– анализа эффективности процедур реагирования на инциденты
ИБ и восстановления после инцидентов, а также идентификации
улучшений системы управления инцидентами ИБ в целом (на основе
полученного опыта);
– обновления базы инцидентов ИБ.
Для этапа «Улучшение» должны быть сформированы процедуры:
– проведения оценки рисков по результатам обработки инцидента;
11
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
– корректировки защитных мер по сдерживанию, устранению
инцидентов ИБ и восстановления после них;
– корректировки нормативных документов.
1.2.3. Создание группы реагирования
на инциденты информационной безопасности
Целью создания ГРИИБ является формирование в организации обученного и доверенного персонала для управления инцидентами ИБ.
Структура, состав и количество персонала ГРИИБ должны соответствовать размеру и структуре организации. ГРИИБ может быть
изолированной группой или отделом. В зависимости от численного
состава организации члены группы могут выполнять несколько
функций внутри ГРИИБ, а также могут привлекаться сотрудники из
различных подразделений организации. Часто ГРИИБ является виртуальной группой, в которой объединяются специалисты по конкретным областям обеспечения ИБ и которые привлекаются в зависимости от типа инцидента ИБ.
Члены группы должны быть доступны для контакта так, чтобы
их имена, а также подробности о контакте с ними были доступными
в организации.
Уровень полномочий членов ГРИИБ должен позволять предпринимать необходимые действия, адекватные инциденту ИБ. Однако
действия, которые могут оказать неблагоприятное влияние на деятельность организации, должны согласовываться с высшим руководством.
Взаимодействие ГРИИБ с подразделениями организации осуществляется по следующим направлениям:
– сотрудничество при обработке инцидента (если сотрудничество необходимо);
– оповещение и информирование об инциденте (при необходимости);
– обеспечение осведомленности сотрудников организации о
процессах и процедурах системы управления инцидентами и их изменениях (прежде всего о процедурах обнаружения и оповещения
об инцидентах).
12
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Взаимодействие ГРИИБ с внешними организациями заключается в следующем:
– оповещение и информирование об инциденте, захватывающем
внешние организации (и, если необходимо, сотрудничество при обработке инцидента);
– обмен информацией и опытом об управлении инцидентами.
1.2.4. Подготовка к обработке инцидентов
При подготовке к обработке инцидента ИБ:
– формируется инфраструктура обработки инцидентов ИБ;
– формируется база известных инцидентов ИБ.
При формировании инфраструктуры обработки инцидентов ИБ
определяются инструментарий и ресурсы, которые могут быть полезны во время обработки инцидента ИБ. К ним относятся: средства
связи, компьютеры, анализаторы пакетов и анализаторы протоколов,
схемы сетей, перечни критичных активов, доверенные версии программного обеспечения и т.п.
База известных инцидентов ИБ формируется на основании всей
доступной информации об инцидентах, существующей в различных
источниках, таких как: международные и национальные нормативные документы, посвященные обработке инцидентов ИБ, данные о
результатах обработки инцидентов ИБ организациями-партнерами
или другими организациями, а также информация об инцидентах ИБ
из различных, но доверенных источников.
Сведения об инцидентах ИБ должны быть представлены в базе
известных инцидентов ИБ в виде, удобном для использования и понятном с точки зрения их развития: от событий, вызывающих инцидент, до возможных негативных последствий инцидента ИБ. Для
этого можно применить, например, методы дерева отказов, дерева
событий и «песочные часы». Применение данных методов для описания сценариев инцидентов ИБ представлено в приложении.
База известных инцидентов ИБ может содержать также сведения о защитных мерах, которые необходимы для обработки инцидентов ИБ.
1.2.5. Формирование последовательности действий
при обработке инцидентов
При планировании обработки инцидентов ИБ формируется последовательность действий при обработке инцидентов ИБ, опреде13
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ляющая начальную обработку инцидента ИБ, которая является общей для всех инцидентов ИБ, и дальнейшую обработку инцидента
ИБ, которая должна быть адаптирована к каждому конкретному типу инцидента ИБ [3].
Последовательность действий, представленная в табл. 1, определяет основные шаги, которые должны быть выполнены при начальной обработке инцидента. После их выполнения обработчики
инцидента должны использовать последовательность действий, которые должны быть адаптированы к каждому конкретному типу инцидента или общую последовательность действий для некатегорированных инцидентов ИБ. В общем виде такая последовательность
представлена в табл. 2.
Таблица 1
Последовательность действий при начальной обработке инцидента
Отметка
Действие
о завершении
Обнаружение и первоначальный анализ инцидента
1
Действия по обнаружению инцидента
1.1
Поиск и анализ признаков инцидентов (предвестников
и указателей)
1.2
Первоначальный анализ нежелательного события
с помощью базы известных инцидентов
2
Определение реальности инцидента
2.1
Сбор и документирование свидетельств (доказательств)
нежелательного события
2.2
Определение события ложным инцидентом.
Завершение обработки инцидента
2.3
Определение события реальным инцидентом.
Продолжение обработки инцидента
3
Определение инцидента по категории (например, отказ
в обслуживании, вредоносный код, неавторизованный
доступ, сбор информации)
4
Далее реализуется контрольный перечень действий
по обработке инцидента определенной категории; если же
инцидент не подходит к принятым категориям,
то реализуется общий контрольный перечень действий
по обработке некатегорированных инцидентов
14
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Последовательности действий обеспечивают для обработчиков
инцидентов руководство по основным действиям, которые должны
быть выполнены. Однако они не определяют обязательную последовательность шагов, которым необходимо следовать всегда.
Таблица 2
Общая последовательность действий
при обработке некатегорированных инцидентов
Отметка
о завершении
Действие
Анализ инцидента ИБ
Сбор и документирование дополнительных свидетельств
1
(доказательств) инцидента для определения его реальности
и значимости
Определение значимости инцидента с точки зрения
2
воздействия на бизнес
Идентификация затронутых активов и прогнозирование,
2.1
какие активы будут затронуты
Оценивание существующих и потенциальных воздействий
2.2
инцидента
Определение по матрице значимости инцидентов условий
2.3 реагирования на основе технического воздействия
и затронутых активов
Сообщение об инциденте соответствующему внутреннему
3
персоналу и внешним организациям
Сдерживание, устранение инцидента и восстановление после инцидента
Получение, документирование, сохранение и обеспечение
4
безопасности и свидетельств (доказательств) инцидента
5
Сдерживание инцидента
6
Устранение инцидента
Идентификация и минимизация всех уязвимостей,
6.1
которые были использованы
Удаление компонентов инцидента, например, вредоносного
6.2
кода и т.д.
7
Восстановление после инцидента
Восстановление затронутых инцидентом систем
7.1
в рабочее состояние
7.2 Проверка функционирования затронутых систем
8
Подготовка завершающего отчета об инциденте
Деятельность после инцидента
9
Анализ обработки инцидента
10 Улучшение системы управления инцидентами
15
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
1.2.6. Классификация инцидентов по значимости
В организации должен быть сформирован порядок обработки
инцидентов ИБ, который заключается в том, что обработка инцидентов ИБ проводится в соответствии с их значимостью на основе двух
факторов:
– существующее и потенциальное техническое воздействие инцидента. Обработчики инцидента должны учитывать не только существующее негативное техническое воздействие инцидента (например, неавторизованный доступ на уровне пользователя к данным), но также,
возможно, будущее техническое воздействие инцидента, если он немедленно не будет сдержан (например, компрометация информационных
активов). Или, например, распространение червя среди рабочих станций может в данный момент вызвать незначительное воздействие, но в
течение нескольких часов трафик «червя» может вызвать сетевой отказ;
– критичность затронутых активов. Активы, затронутые инцидентом (например, Web-серверы, связность Internet, рабочие станции
пользователя и приложения), имеют различное значение для организации. Критичность актива основана, главным образом, на его данных или услугах, взаимозависимостях с другими активами.
Критичность затронутых активов и существующее и потенциальное техническое воздействие инцидента определяют влияние инцидента ИБ на бизнес и значимость инцидента (критичная – значимость 1, высокая – значимость 2, средняя – значимость 3, низкая –
значимость 4, несущественная – значимость 5). Значимость инцидента
указывает на приоритетность его обработки, на степень его опасности. Например, компрометация рабочей станции пользователя может
привести к незначительному ущербу, связанному с потерей целостности или конфиденциальности только пользовательских информационных активов (значимость 4). Доступ же на системном уровне может
привести к серьезным нарушениям целостности, конфиденциальности
и доступности критичных информационных активов, услуг и сервисов
(значимость 1).
Члены ГРИИБ, выполняющие роли по обработке инцидентов
ИБ, должны определять значимость каждого инцидента, основанную
на оценке его воздействия на бизнес.
В организации руководство по значимости инцидентов ИБ
должно быть задокументировано, например, в виде матрицы, показанной в табл. 3.
В организации должны быть сформированы такие матрицы значимости инцидентов ИБ на основе учета своих особенностей, интересов.
16
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Например, организация может иметь не пять, а больше или меньше
уровней значимости инцидентов. Несущественные инциденты, такие
как заражение неопасными вирусам, могут быть обработаны персоналом ИТКС, а не группой реагирования на инциденты ИБ.
Таблица 3
Примерная матрица для определения значимости инцидентов ИБ
Критичность (важность) активов, затрагиваемых
в настоящее время или которые, по всей
вероятности, будут затронуты инцидентом
Высокая
Существующее
(например,
воздействие
Средняя
связность
Низкая
или вероятное
(например,
с Internet,
(например,
будущее воздействие
серверы файлов,
Web-серверы,
рабочие
инцидента
рабочие станции серверы печати,
станции
почтовый
системных
пользователей)
сервер)
и ИБ администраторов, сервер
мониторинга)
Доступ
Значимость 1
Значимость 2
Значимость 2
на системном уровне
Неавторизованная
Значимость 1
Значимость 2
Значимость 3
модификация данных
Неавторизованный
доступ
Значимость 1
Значимость 2
Значимость 3
к чувствительным
данным
Неавторизованный
доступ на уровне
Значимость 2
Значимость 3
Значимость 4
пользователя
Недоступность услуг
Значимость 2
Значимость 3
Значимость 4
Раздражение
(периодическое
сообщение на экране,
Значимость 2
Значимость 5
Значимость 5
всплывающие картинки,
закрывающие экран
и т.д.)
1.2.7. Обеспечение осведомленности
и обучение управлению инцидентами
Управление инцидентами ИБ – это процесс, который должен
поддерживаться персоналом, обученным деятельности по обработке
инцидентов ИБ, и сотрудниками организации, осведомленными
о вопросах ИБ.
17
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Должна существовать специальная программа обучения для
ГРИИБ, а при необходимости и для персонала, ответственного за ИБ,
и системных администраторов и администраторов ИБ. Для каждой
группы, участвующей в управлении инцидентами, может потребоваться свой, отличающийся от других уровень обучения, зависящий
от частоты и степени их взаимодействия с системой управления инцидентами ИБ.
Члены ГРИИБ должны быть компетентными в отношении процедур и процессов планирования, использования, анализа и улучшения системы управления инцидентами ИБ. Обучение членов ГРИИБ
должно включать специальные упражнения, связанные с обработкой
инцидентов ИБ, и тестирование членов группы.
Инструктажи с сотрудниками организации, проводимые с целью
обеспечения осведомленности, должны включать:
– основы системы управления инцидентами ИБ, включая ее
сферу действия и последовательность действий по управлению инцидентами ИБ;
– информацию о процедурах обнаружения событий и инцидентов;
– инструкции о том, как сообщать о событиях и инцидентах ИБ;
– информацию об известных инцидентах и о результатах управления инцидентами ИБ.
В некоторых случаях желательно специально включить вопросы
обеспечения осведомленности об управлении инцидентами ИБ в
другие программы, например, в программы обеспечения осведомленности об ИБ.
1.3. Использование системы управления
инцидентами информационной безопасности
1.3.1. Последовательность действий при обработке инцидента
Управление инцидентами ИБ на этапе использования системы
управления инцидентами начинается с обнаружения события ИБ и
завершается либо определением ложности инцидента, либо успешной обработкой инцидента, либо введением антикризисных действий. Последовательность действий при обработке событий и инцидентов ИБ на этапе использования системы управления инцидентами представлена на рис. 2.
18
Время
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. 2. Последовательность обработки событий
и инцидентов ИБ на этапе использования
системы управления инцидентами
1.3.2. Обнаружение и анализ инцидента
Обнаружение инцидента ИБ осуществляется с помощью систем обнаружения вторжений, антивирусного программного обеспечения (ПО), записей мониторинга ИБ, сотрудников организации
на основе признаков инцидентов ИБ. Признаки инцидентов ИБ
можно разделить на две категории: «указатели» и «предвестники».
«Предвестник» является признаком того, что инцидент ИБ может
произойти в будущем. «Указатель» – это признак того, что инцидент ИБ, возможно, случился или может случиться сейчас. Примеры указателей таковы:
19
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
– антивирусное ПО предупреждает, что в системе появился вирус;
– пользователи жалуются на медленный доступ к узлам Internet;
– системный администратор обнаруживает файл с необычными
характеристиками (большой размер, неизвестное происхождение и т.д.);
– приложение регистрирует многочисленные неудачные попытки доступа из незнакомой удаленной системы;
– системный администратор обнаруживает большое число почтовых сообщений с подозрительным содержанием.
Примеры предвестников таковы:
– публикация информации об уязвимостях операционных систем или ПО;
– угроза от группы хакеров, заявляющих, что они будут атаковать организацию.
Предвестники и указатели инцидентов ИБ могут быть обнаружены сотрудником или сотрудниками, заметившими признаки нештатной ситуации или похожей на нее. Сотрудник, заметивший чтото необычное или информированный об этом автоматическими
средствами, должен сообщить группе реагирования на инциденты о
событиях ИБ.
Сотрудник, сообщивший о событии ИБ, должен заполнить отчетную форму, установленную для системы управления инцидентов
ИБ, так, чтобы сообщить как можно больше информации, доступной
ему в тот момент. Предпочтительно, чтобы эта форма была в электронном виде (например, в виде сообщений электронной почты),
чтобы ее можно было передать безопасным образом. Форма сообщения «Отчет о событии ИБ» должна содержать следующую информацию:
а) дата и время обнаружения события;
б) дата и время оповещения о событии;
в) информация о лице, сообщившем о событии ИБ;
г) описание события:
– что произошло;
– как произошло;
– почему произошло;
– затронутые инцидентом активы;
– выявленные уязвимости.
20
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
При заполнении отчетной формы важны не только точность, но
и своевременность. Не следует задерживать представление отчетной
формы о событии ИБ по причине уточнения ее содержания – уточнение можно прислать позже.
Анализ инцидентов ИБ начинается с того, что член ГРИИБ
должен зафиксировать получение заполненной отчетной формы и
проанализировать ее. Далее группа реагирования должна немедленно начать запись всех фактов, касающихся этого события. Наряду с
записями мониторинга каждое мероприятие, предпринятое со времени обнаружения события, в том числе применение защитных мер,
должно быть задокументировано и отмечено временем. Каждый документ, касающийся инцидента, должен быть с датой и подписан
обработчиком инцидента. Эта информация и другие свидетельства,
собранные на этой стадии, могут потребоваться в будущем для дисциплинарного или правового расследования.
Если событие ИБ определяется как ложное, то форма «Отчет о
событии ИБ» дополняется информацией о проведенных мероприятиях, обоснованием ложности события ИБ и записывается в базу
данных событий ИБ.
Если событие ИБ определено как вероятный инцидент ИБ, то
заполняется форма «Отчет об инциденте ИБ», в которой должно
описываться следующее:
а) дата и время обнаружения инцидента;
б) дата и время оповещения об инциденте;
в) информация о сообщившем сотруднике;
г) описание инцидента:
– что произошло;
– как произошло;
– почему произошло;
– реальное или потенциальное воздействие инцидента ИБ на
бизнес организации;
– затронутые инцидентом активы;
– предполагаемая значимость инцидента ИБ.
Для наиболее значимых инцидентов (в зависимости от количества уровней значимости инцидентов, например, для инцидентов
средней значимости и выше) необходимо определить их реальное
или потенциальное воздействие на бизнес организации исходя из
следующих возможных последствий:
21
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
– финансовые потери/прерывание бизнес-операций;
– ущерб коммерческим и экономическим интересам;
– ущерб информации, содержащей персональные данные;
– нарушение правовых и нормативных требований;
– ущерб престижу организации.
Если инцидент ИБ был разрешен, то отчет должен содержать
также информацию о предпринятых защитных мерах и любом полученном опыте (например, защитные меры, которые должны быть
предприняты для предотвращения повторного появления инцидента
или подобных инцидентов).
После заполнения отчетной формы, она должна быть введена в
базу данных инцидентов ИБ.
Если все еще остается некая неопределенность относительно
аутентичности инцидента ИБ или полноты полученной информации,
то члены ГРИИБ должны провести вторичную оценку для определения реальности или ложности инцидента. Для этого необходимо собрать любую дополнительную информацию о событии ИБ, которая
требуется и доступна, в том числе от лица, заполнившего отчетную
форму о событии ИБ.
Если инцидент ИБ определяется как ложный, то форма «Отчет
об инциденте ИБ» дополняется информацией о проведенных мероприятиях, обоснованием ложности инцидента ИБ и записывается в
базу данных инцидентов ИБ.
Если инцидент ИБ определяется как реальный, то группа реагирования определяет сферу действия инцидента, а именно: какие сети, компьютеры или приложения затронуты; кто или что явилось источником; на что он повлиял или мог повлиять. Уточняется значимость инцидента (по шкале, принятой в организации) и определяется
реальное или потенциальное воздействие инцидента ИБ на бизнес
организации исходя из следующих возможных последствий:
– финансовые потери/прерывание бизнес-операций;
– ущерб коммерческим и экономическим интересам;
– ущерб информации, содержащей персональные данные;
– нарушение правовых и нормативных требований;
– ущерб престижу организации.
Проведенный анализ должен обеспечить ГРИИБ информацией,
достаточной для определения последующих действий, связанных с
реагированием на инцидент, таких как сдерживание, устранение ин22
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
цидента. При сомнении в выборе последующих действий обработчики инцидента должны предполагать худшее развитие ситуации,
пока дополнительный анализ не укажет на обратное.
1.3.3. Реагирование на инциденты
1.3.3.1. Сдерживание инцидента
Когда инцидент ИБ был обнаружен и проанализирован, необходимо обеспечить сдерживание инцидента ИБ до того, как может
быть нанесен ущерб активам системы.
При сдерживании инцидента важно принять решение о стратегии сдерживания (например, останов системы, отключение ее от
кабельной или беспроводной сети, блокирование определенных
функций). Для принятия таких решений необходимо, чтобы стратегии и процедуры для сдерживания инцидента были предопределены. Организации должны определить приемлемые риски при работе с инцидентами и разработать соответствующие стратегии сдерживания.
Стратегии сдерживания отличаются в зависимости от типа инцидента. Организации должны создавать отдельные стратегии сдерживания для каждого типа инцидента.
В определенных случаях сдерживание инцидента может быть
отложено на некоторое время, чтобы провести мониторинг активности атакующего для сбора дополнительных показаний. Однако риск
при этом увеличивается, так как стратегия отложенного сдерживания является опасной, поскольку атакующий может успеть нанести
ущерб.
При обработке инцидента владельцы системы обычно стремятся
идентифицировать атакующего. Хотя эта информация и является
важной (особенно, если организация хочет привлечь атакующего к
ответственности), но обработчики инцидента должны прежде всего
решать задачу сдерживания, устранения и восстановления. Идентификация атакующего может быть длительным и бесполезным процессом, который может отвлечь ГРИИБ от достижения ее главной
цели – минимизации воздействия на бизнес.
Для идентификации атакующего необходимо выполнить следующие действия:
– определение IP-адреса атакующего. Задача заключается в определении реальности этого адреса, например, с помощью тестирования и трассировок подозрительного узла;
23
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
– сканирование системы атакующего. Чтобы проверить адрес
атакующего и собрать больше информации по атакующему, применяют, например, сканеры уязвимостей;
– мониторинг возможных каналов связи атакующего.
По завершении процедуры сдерживания необходимо оценить,
находится ли инцидент ИБ под контролем. Если подтверждается,
что инцидент ИБ находится под контролем, то члены ГРИИБ должны перейти к дальнейшим действиям по реагированию, направленным на устранение инцидента ИБ и восстановление нормальной работы системы после инцидента.
Если не подтверждается, что инцидент ИБ находится под контролем, то члены ГРИИБ должны инициировать «антикризисные»
действия.
1.3.3.2. Устранение инцидента и восстановление после инцидента
Действия по устранению инцидента и восстановлению после
инцидента заключаются в том, что после того, как инцидент был
сдержан, может понадобиться устранить элементы инцидента, такие
как ликвидация вредоносного кода, блокирование взломанных учетных записей или паролей пользователя. Для некоторых инцидентов
устранение либо не является необходимым, любо выполняется во
время восстановления. При восстановлении члены ГРИИБ и системные администраторы подготавливают системы к нормальной работе.
При восстановлении могут быть реализованы следующие действия: восстановление программных средств из резервных копий, запуск компонентов систем с доверенного состояния, замена скомпрометированных файлов доверенными версиями, изменение паролей. Если вследствие уничтожения журналов регистрации инцидентов ИБ становится неизвестным полный объем информации об инциденте, тогда может потребоваться полная перестройка системы,
сервиса и (или) сети.
1.3.3.3. «Антикризисные» действия
Если по завершении процедур сдерживания группа реагирования определила, что инцидент ИБ не находится под контролем, то
члены ГРИИБ должны для обработки инцидента предпринять «антикризисные» действия. Для этого используется, например, предварительно разработанный план непрерывности бизнеса.
Обработка всех возможных инцидентов ИБ, которые могут повлиять на доступность, целостность или разрушение системы, долж24
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
на быть определена в плане непрерывности бизнеса организации.
Эти варианты обработки инцидентов должны быть непосредственно
связаны с приоритетами бизнеса организации и соответствующими
временными рамками восстановления и, следовательно, с максимально приемлемым временем простоя систем и их компонентов.
В плане необходимо определить:
– предупреждающие и поддерживающие меры обеспечения непрерывности бизнеса;
– организационную структуру и ответственности, связанные с
управлением непрерывностью бизнеса;
– основные положения непрерывности бизнеса.
1.3.3.4. Формирование и хранение свидетельств инцидентов
После устранения инцидентов ИБ и восстановления после них
необходимо сформировать окончательный отчет по каждому инциденту. Отчет обеспечивает справочные данные, которые могут быть
использованы при обработке подобных инцидентов. Создание хронологии событий является важным по юридическим причинам, так
как дает возможность определить оценку ущерба, вызванного инцидентом, в терминах любой потери программного обеспечения и файлов, вреда аппаратным средствам и затрат персонала (включая услуги по восстановлению).
Для формирования такого отчета, во-первых, обновляется информация в форме «Отчет об инциденте ИБ»:
– что представляет собой инцидент ИБ;
– что явилось его причиной, чем или кем он был вызван;
– на что он повлиял или мог повлиять;
– реальное или потенциальное воздействие инцидента ИБ на бизнес организации;
– значимость инцидента ИБ (по шкале опасности, принятой в
организации);
– действия, предпринятые для разрешения инцидента.
Изучение характеристик инцидента может указать на уязвимости и угрозы ИБ. Эти данные могут быть использованы в процессе
оценки риска.
Во-вторых, собираются статистические данные об инцидентах,
включающие:
25
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
– число обработанных инцидентов. Обработка большего числа
инцидентов необязательно лучше. Например, число инцидентов, которые обработаны, может уменьшиться из-за применения более лучших защитных мер, а не из-за некомпетентности ГРИИБ. Следует
производить раздельные подсчеты инцидентов для каждой категории инцидентов (например, неавторизованный доступ, отказ в обслуживании);
– время, затраченное на инцидент. Для каждого инцидента время может быть измерено несколькими способами:
– общее время, затраченное на обработку инцидента ИБ (в том
числе подготовка к инциденту);
– время от начала инцидента ИБ до его решения;
– время для каждого этапа обработки инцидента (например, сдерживание, восстановление).
В организации должно быть определено, как долго должны сохраняться свидетельства (доказательства) инцидента. При этом
должны быть учтены следующие факторы:
– судебное преследование. Если предполагается, что атакующий
будет преследоваться по закону, то может оказаться необходимым
сохранить свидетельства инцидента, пока не будут завершены все
юридические действия;
– сохранение данных. Организация может иметь политику, положения сохранения данных, которые устанавливают, как долго могут сохраняться определенные типы данных;
– затраты. Если организация хранит много компонентов инцидентов (например, накопители) и в течение нескольких лет, то затраты могут быть существенными.
1.4. Анализ обработки инцидентов
1.4.1. Изучение полученного опыта
После завершения инцидента ИБ важно извлечь уроки из его
обработки, чтобы в следующий раз этот инцидент ИБ можно было
быстро обнаружить и предпринять действия. Полученный опыт рассматривается с точки зрения:
– новых или измененных требований к защитным мерам ИБ.
Это могут быть технические или нетехнические защитные меры.
В зависимости от полученных уроков требования могут включать
необходимость совершенствования защитных мер и проведения ин26
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
структажа для сотрудников с целью обеспечения осведомленности в
вопросах безопасности, а также необходимость пересмотра или разработки нормативных документов по ИБ;
– изменений в системе управления инцидентами ИБ и ее процессах, формах отчета и базе данных событий и инцидентов ИБ.
Кроме того, необходимо проанализировать последовательность
инцидентов ИБ на наличие опасных тенденций, что может быть использовано для определения потребности в защитных мерах или изменения подходов к обработке инцидентов ИБ.
1.4.2. Определение улучшения безопасности
В процессе анализа, проведенного после разрешения инцидента
ИБ, могут быть определены новые защитные меры или изменения
для существующих как необходимые. Рекомендации и соответствующие требования к защитным мерам могут оказаться такими, что
их невозможно будет реализовать немедленно по финансовым или
эксплуатационным причинам. В таком случае они должны быть
предусмотрены в долгосрочных целях организации.
1.4.3. Определение улучшения системы управления инцидентами
После разрешения инцидента члены ГРИИБ должны проанализировать все произошедшее с целью оценки и определения степени
результативности реагирования на инцидент ИБ. Этот анализ предназначен для выявления успешно задействованных элементов системы управления инцидентами ИБ и определения потребности в каких-либо улучшениях.
Если значимость инцидента высока, то после разрешения инцидента необходимо провести совещание всех заинтересованных сторон. На этом совещании должны рассматриваться следующие вопросы:
– «Работали ли должным образом процедуры, принятые в системе управления инцидентами ИБ?»;
– «Применялись ли процедуры или методы, которые способствовали обнаружению инцидентов?»;
– «Применялись ли процедуры или инструменты, которые использовались для сдерживания и устранения инцидента?»;
– «Применялись ли процедуры, помогающие восстановлению
информационных систем после инцидента?».
27
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Результаты совещания должны быть задокументированы и по
этим результатам должны быть осуществлены действия по улучшению системы управления инцидентами.
1.5. Улучшение системы управления инцидентами
1.5.1. Улучшение оценки рисков
и управления информационной безопасностью
В зависимости от значимости обработанного инцидента ИБ при
оценке рисков и управлении ИБ может потребоваться учитывать новые угрозы и уязвимости. В результате оценки рисков и управления
ИБ может возникнуть необходимость внесения изменений в существующие или применения новых защитных мер.
1.5.2. Улучшение безопасности
Организация должна реализовывать принятые решения по улучшению ИБ в соответствии с выявленными в результате анализа потребностями в реализации обновленных и (или) новых защитных мер.
Непосредственно после завершения инцидента ИБ должны быть
обновлены, если потребуется, политики и процедуры ИБ, чтобы
учесть любые проблемные вопросы, идентифицированные в процессе управления инцидентами ИБ. Важной целью ГРИИБ и руководства ИБ организации является распространение сведений об обновлениях политик и процедур ИБ среди всех причастных сотрудников
организации. Эта цель может быть достигнута с помощью включения информации о принятых изменениях в программу осведомления
сотрудников в вопросах безопасности.
1.5.3. Улучшение системы управления инцидентами
Обоснованные и утвержденные по результатам анализа обработки
инцидентов ИБ изменения, предназначенные для улучшения областей
системы управления инцидентами ИБ, должны быть внесены в обновленные документы системы управления инцидентами ИБ.
Изменения в процессах, процедурах и в отчетных формах системы управления инцидентами ИБ должны быть тщательно проверены и протестированы до введения в эксплуатацию.
Контрольные вопросы
1. Определение инцидента кибербезопасности. Примеры инцидентов кибербезопасности.
2. Этапы управления инцидентами информационной безопасности.
28
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3. Процессы планирования системы управления инцидентами
кибербезопасности.
4. Формирование политики управления инцидентами ИБ.
5. Формирование процедур управления инцидентами информационной безопасности.
6. Создание ГРИИБ.
7. Подготовка к обработке инцидентов.
8. Формирование последовательности действий при обработке
инцидентов.
9. Классификация инцидентов по значимости.
10. Обеспечение осведомленности и обучение управлению инцидентами.
11. Использование системы управления инцидентами информационной безопасности. Последовательность действий при обработке
инцидента.
12. Обнаружение и анализ инцидента.
13. Реагирование на инциденты. Сдерживание инцидента. Устранение инцидента и восстановление после инцидента. «Антикризисные» действия. Формирование и хранение свидетельств инцидентов.
14. Анализ обработки инцидентов. Изучение полученного опыта. Определение улучшения безопасности. Определение улучшения
системы управления инцидентами.
15. Улучшение системы управления инцидентами. Улучшение
оценки рисков и управления информационной безопасностью. Улучшение безопасности. Улучшение системы управления инцидентами.
29
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
2. Управление инцидентами
неавторизованного доступа
2.1. Определение инцидента неавторизованного доступа.
Цели инцидента неавторизованного доступа
Инцидент неавторизованного доступа состоит из несанкционированных попыток доступа в систему. Неавторизованный доступ обычно
реализуется через использование уязвимостей операционной системы
или приложений, использование имен пользователей и паролей или их
подбор. Целями инцидента неавторизованного доступа могут быть:
– дистанционная компрометация почтового сервера;
– дискредитация Web-сервера;
– извлечение файлов с паролями;
– перехват соединения или ложное направление легитимных сетевых соединений;
– просмотр конфиденциальных данных, например, записи платежных ведомостей и медицинской информации, без авторизации;
– запуск анализаторов на рабочей станции с целью захвата имен
пользователей и паролей;
– соединение с незащищенным модемом и получение доступа к
внутренней сети;
– выполнение роли администратора, например, переустановка
пароля e-mail и обучение новому паролю;
– использование необслуживаемой зарегистрированной рабочей
станции без разрешения.
2.2. Планирование системы управления инцидентами
неавторизованного доступа
2.2.1. Подготовка к обработке инцидента
При подготовке к обработке инцидента необходимо построить возможные сценарии известных инцидентов неавторизованного доступа.
Сценарии развития инцидента строятся на основе критических
событий, которые приводят к инциденту, и предшествующих им нежелательных событий. В табл. 4 приведены критические события и
предшествующие им нежелательные события инцидента неавторизованного доступа.
30
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Таблица 4
Нежелательные события инцидента
неавторизованного доступа
Критическое событие
Нежелательные события
Неавторизованное
использование узла
Использование узла для атаки других систем.
Создание новых учетных записей
на административном уровне.
Нарушение работоспособности узла.
Модификация или дополнение процессов/услуг.
Модификация критичных файлов, программ,
библиотек системы и файлов конфигурации.
Получение привилегированного доступа к узлу
Неавторизованная
модификация данных
Удаление или модификация содержимого
Web-сервера.
Удаление или модификация содержимого
FTP-сервера.
Нарушение работоспособности узла.
Недоступность услуг, сервисов
Модификация или дополнение процессов/услуг.
Модификация критичных файлов, программ,
Неавторизованное
библиотек системы и файлов конфигурации.
использование учетной Недоступность услуг, сервисов.
записи пользователя
Получение привилегированного доступа к узлу.
Блокирование учетных записей пользователей.
Загрузка инструментария злоумышленника
Неавторизованный
доступ к базе данных
Несанкционированное копирование
или модификация данных.
Несанкционированный доступ к файлам паролей
На рис. 3 представлены примеры сценариев развития инцидента
неавторизованного доступа.
Инцидент неавторизованного доступа может привести к раскрытию конфиденциальной информации, что повлечет за собой денежные потери и ущерб репутации. Также инцидент неавторизованного доступа может привести к прерыванию одного или нескольких
бизнес-процессов и потере данных, что в свою очередь вызовет потерю производительности, вследствие чего организации будет нанесен материальный ущерб и ущерб репутации.
На рис. 4 представлены примеры сценариев последствий инцидента неавторизованного доступа.
31
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Несанкционированный доступ
к файлам паролей
Рис. 3. Сценарии развития инцидента неавторизованного доступа
Раскрытие
конфиденциальной
информации
Неавторизованный
доступ
Материальный
ущерб
Прерывание
бизнес-процесса/
процессов
Потеря
производительности
Ущерб репутации
Потеря данных
Рис. 4. Сценарии последствий инцидента неавторизованного доступа
32
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Удаление или модификация
содержимого Web-сервера
33
Несанкционированный доступ
к файлам паролей
Рис 5. Сценарии инцидента неавторизованного доступа
33
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Сценарии инцидента неавторизованного доступа, сочетающие
сценарии развития и последствий инцидента неавторизованного
доступа, представлены на рис. 5.
Данная схема позволяет проанализировать сценарии инцидента
от вызвавших его нежелательных событий до негативных последствий, которые он за собой повлечет.
2.2.2. Выбор защитных мер
Защитные меры по управлению доступом к системам, выбранные на основе результатов оценки рисков, нацелены на противодействие реализации выявленных угроз и снижение возможности использования уязвимостей, связанных с управлением доступом. Такими защитными мерами, например [4], могут быть:
а) управление доступом пользователей к системе:
– процедуры регистрации и снятия с регистрации пользователей
в отношении доступа к системам и сервисам;
– предоставление и контроль привилегий и прав доступа пользователям к определенным системам, программному обеспечению,
операционной системе и т.д.;
– парольная защита;
б) управление сетевым доступом:
– определение перечня разрешенных сетевых услуг;
– мероприятия и процедуры по защите от несанкционированного подключения к сетевым сервисам;
– аутентификация удаленных пользователей;
– аутентификация удаленных узлов;
– управление маршрутизацией сети;
– контроль сетевых соединений;
в) управление доступом к операционной системе:
– процедуры идентификации и аутентификации узла;
– процедуры идентификации и аутентификации пользователей;
г) управление доступом к приложениям:
– предоставление и контроль прав доступа пользователей к приложениям;
– изоляция систем, обрабатывающих важную информацию;
– мониторинг доступа и использования систем.
34
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Кроме того, по результатам оценки рисков могут быть выбраны
защитные меры, позволяющие обнаруживать нежелательные события, ведущие к инциденту неавторизованного доступа. К таким защитным мерам, например, могут относиться:
– сетевая и узловая системы обнаружения вторжений (СОВ);
– межсетевой экран (МСЭ).
Однако ввиду наличия остаточного риска, появления новых угроз и уязвимостей выбранных защитных мер может быть недостаточно, и инциденты кибербезопасности будут происходить. Необходима своевременная и оперативная обработка инцидентов кибербезопасности, чтобы снизить возможный ущерб от них.
На основе анализа сценариев инцидента должны быть определены защитные меры по сдерживанию, устранению инцидента и восстановлению после него. Эти меры выбираются и реализуются членами ГРИИБ в соответствии со сценарием развития инцидента.
К защитным мерам, сдерживающим инцидент неавторизованного доступа, относятся:
– изолирование узлов и систем, подвергшихся инциденту;
– блокирование услуг, подвергшихся инциденту;
– блокирование маршрутов атакующего;
– блокирование учетных записей пользователей, которые могли
быть использованы при инциденте.
Мерами по устранению инцидента и восстановлению после инцидента неавторизованного доступа могут быть:
– восстановление из резервной копии атакованной ОС или приложения;
– изменение всех паролей во всех системах, которые имели отношения с атакованной системой, а также пересмотр процедур парольной защиты;
– идентификация всех уязвимостей, которые были использованы, и определение стратегии для их уменьшения.
На рис. 6 представлен пример применения защитных мер в соответствии с последовательностью событий сценария инцидента неавторизованного доступа, начинающегося с события «модификация
или дополнение процессов/услуг». На рисунке приняты следующие
сокращения: «Р» – защитные меры, определенные на основе результатов оценки рисков, «С» – меры по сдерживанию инцидента,
35
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
«У» – меры по устранению инцидента, «В» – меры по восстановлению после инцидента.
Рис. 6. Пример применения защитных мер
на одном из сценариев инцидента
неавторизованного доступа
2.2.3. Формирование последовательности действий
при обработке инцидентов неавторизованного доступа
Для обеспечения эффективного реагирования на инцидент в организации должна быть сформирована последовательность действий при
обработке инцидентов неавторизованного доступа. Эта последовательность приводится в табл. 5. Последовательность действий может
меняться в зависимости от особенностей инцидентов и стратегий по
сдерживанию инцидента, выбранных конкретной организацией.
1
1
2
2.1
2.2
2.3
3
Таблица 5
Последовательность действий
при обработке инцидента неавторизованного доступа
Действие
Завершено
2
3
Анализ инцидента неавторизованного доступа
Сбор и документирование дополнительных свидетельств
(доказательств) инцидента для определения его реальности
и значимости
Определение значимости инцидента с точки зрения его
воздействия на бизнес
Идентификация затронутых активов и прогнозирование,
какие активы могут быть затронуты
Оценивание существующих и потенциальных воздействий
инцидента
Определение по матрице значимости инцидентов условий
реагирования на основе технического воздействия
и затронутых активов
Сообщение об инциденте соответствующему внутреннему
персоналу и внешним организациям
36
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Окончание табл. 5
1
2
3
Сдерживание, устранение инцидента и восстановление после инцидента
4
Выполнение начального сдерживания инцидента
(например, блокирование учетных записей пользователя,
которые могли быть использованы при атаке)
5
Получение, документирование, сохранение и обеспечение
безопасности свидетельств (доказательств) инцидента
6
6.1
6.2
Необходимость удостовериться в сдерживании
инцидента
Анализ инцидента и определение, достаточно ли было
сдерживание (включая проверку других систем
на признаки вторжения)
Реализация дополнительных мер сдерживания
при необходимости
7
Устранение инцидента
7.1
Идентификация и минимизация всех уязвимостей,
которые были использованы
7.2
Удаление компонентов инцидента
8
Восстановление после инцидента
8.1
Восстановление затронутых инцидентом систем
к рабочему состоянию
8.2
Проверка функционирования затронутых систем
9
Подготовка завершающего отчета об инциденте
Деятельность после инцидента
2.2.4. Формирование порядка обработки
инцидента неавторизованного доступа
В организации должен быть определен порядок обработки инцидентов неавторизованного доступа в зависимости от их значимости. Примерная матрица определения значимости инцидентов неавторизованного доступа показана в табл. 6.
Заголовки столбцов показывают различную степень критичности активов, а заголовки строк  различные категории технического
воздействия. Уровень значимости инцидента в матрице определяет
приоритетность его обработки.
37
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Таблица 6
Примерная матрица определения значимости инцидентов
неавторизованного доступа
Существующее
воздействие или
вероятное
будущее
воздействие
инцидента
Критичность (важность) активов, затрагиваемых
в настоящее время или которые, по всей вероятности,
будут затронуты инцидентом
Высокая (например,
Средняя
связность с Internet,
(например,
Web-серверы,
серверы файлов,
рабочие станции
серверы печати,
системных и ИБ
почтовый
администраторов,
сервер)
сервер мониторинга)
Низкая
(например,
рабочие
станции
пользователей)
Неавторизованный
доступ
на системном
уровне
Значимость 1
Значимость 2
Значимость 3
Неавторизованный
доступ
к чувствительным
данным
Значимость 1
Значимость 3
Значимость 3
Неавторизованный
доступ на уровне
пользователя
Значимость 2
Значимость 3
Значимость 4
Раздражение
(приставание)
Значимость 2
Значимость 5
Значимость 5
2.3. Использование системы управления
инцидентами неавторизованного доступа
2.3.1. Обнаружение и анализ инцидента
неавторизованного доступа
Обнаружение и анализ инцидентов неавторизованного доступа
может происходить с помощью различных «предвестников» и указателей инцидента. В табл. 7 перечисляются возможные «предвестники»
инцидента неавторизованного доступа и приводятся действия, которые
могут предотвратить появление инцидента.
38
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Таблица 7
Предвестники инцидента неавторизованного доступа
и действия по их предотвращению
Предвестник
Действия по предотвращению
Разведывательная активность
с целью составления структуры
узлов и услуг и идентификации
уязвимостей. Активность может
включать просмотры портов,
уязвимостей, тесты по методу
запрос-ответ, трассировку
маршрутов и захват заголовков,
баннеров.
Такая активность обнаруживается,
главным образом, с помощью СОВ
и с помощью анализа журналов
мониторинга ИБ
Обработчики инцидентов должны
выявить особые изменения
при зондировании, например,
неожиданный интерес к конкретному
номеру порта или узлу. Если эта
активность указывает на уязвимость,
которая может быть использована,
организация может иметь время
заблокировать будущие атаки путем
уменьшения этой уязвимости
(например, блокирование услуги,
модифицирование правил сетевого экрана)
О возможности неавторизованного
доступа сообщается публично,
и это представляет значительную
угрозу для организации
Организация должна расследовать
возможности неавторизованного
доступа и, если возможно, изменить
средства управления ИБ, чтобы
минимизировать потенциальное
воздействие этого инцидента
на организацию
Указатели инцидента – это признаки нежелательных событий
(см. табл. 4), которые могут быть выявлены с помощью:
– сообщений сетевых и узловых СОВ;
– просмотра журналов мониторинга ИБ;
– просмотра статистики МСЭ;
– сообщения пользователей об отклонениях в работе систем.
Указатели нежелательных событий инцидента неавторизованного доступа приведены в табл. 8.
39
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Таблица 8
Указатели инцидента неавторизованного доступа
и соответствующие им нежелательные события
Возможные указатели
Нежелательные события
1
2
Использование узла для атаки
Необычный трафик к узлу и от узла
других систем
Модификация или дополнение
Изменения в конфигурации систем,
процессов/услуг.
включающие:
Модификация критичных файлов,
– неожиданные открытые порты;
программ, библиотек системы и файлов
– изменения в состоянии систем
конфигурации.
(повторные старты, закрытия);
Недоступность услуг, сервисов.
Нарушение работоспособности узла.
– изменения в политиках журнала
Получение привилегированного доступа
регистрации и данных;
к узлу.
– новая учетная запись
Блокирование учетных записей
пользователя или группы
пользователей.
на административном уровне
Загрузка инструментария злоумышленника
Модификация или дополнение
процессов/услуг.
Чрезмерная активность в сети
Нарушение работоспособности узла.
Недоступность услуг, сервисов.
Загрузка инструментария злоумышленника
Использование узла для атаки других
систем.
Модификация или дополнение
процессов/услуг.
Модификация критичных файлов,
программ, библиотек системы и файлов
конфигурации.
Сообщения пользователей
Недоступность услуг, сервисов.
о недоступности услуг, серверов
Нарушение работоспособности узла.
Блокирование учетных записей
пользователей.
Загрузка инструментария злоумышленника.
Удаление или модификация содержимого
Web-сервера.
Удаление или модификация содержимого
FTP-сервера
Сообщение пользователей
Удаление или модификация содержимого
о модификации данных (например,
Web-сервера.
искаженный Web-сайт,
Удаление или модификация содержимого
Web-страница)
FTP-сервера
40
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Продолжение табл. 8
1
Сообщения об обнаружении
вторжений в сеть или к узлу
Новые файлы или каталоги
с необычными именами
(например, двоичные символы,
пробелы, точки)
Необычные сообщения
журналов операционной
системы и приложений
Попытки доступа к критичным
файлам
2
Использование узла для атаки других
систем.
Нарушение работоспособности узла.
Удаление или модификация
содержимого Web-сервера.
Удаление или модификация
содержимого FTP-сервера.
Нарушение работоспособности узла.
Недоступность услуг, сервисов.
Загрузка инструментария
злоумышленника.
Несанкционированное копирование
или модификация данных.
Несанкционированный доступ
к файлам паролей
Несанкционированное копирование
или модификация данных.
Модификация или дополнение
процессов/услуг.
Модификация критичных файлов,
программ, библиотек системы и файлов
конфигурации.
Загрузка инструментария
злоумышленника.
Удаление или модификация содержимого FTP-сервера
Использование узла для атаки других
систем.
Модификация или дополнение
процессов/услуг.
Модификация критичных файлов,
программ, библиотек системы и файлов
конфигурации
Модификация критичных файлов,
программ, библиотек системы и файлов
конфигурации.
Получение привилегированного
доступа к узлу.
Несанкционированное копирование
или модификация данных.
Несанкционированный доступ
к файлам паролей
41
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Окончание табл.8
1
Увеличение использования
ресурсов
Неправильное использование
учетных записей (например,
применяется неиспользуемая
учетная запись, учетная запись
используется многими
пользователями, большое число
заблокированных учетных
записей)
Записи журнала proxy-сервера,
показывающие загрузку
инструментария злоумышленника
2
Использование узла для атаки других
систем.
Модификация или дополнение
процессов/услуг.
Нарушение работоспособности узла.
Недоступность услуг, сервисов.
Загрузка инструментария
злоумышленника
Использование узла для атаки других
систем.
Создание новых учетных записей или
группы на административном уровне.
Получение привилегированного доступа
к узлу.
Блокирование учетных записей
пользователей.
Загрузка инструментария
злоумышленника.
Несанкционированное копирование
или модификация данных.
Несанкционированный доступ к файлам
паролей
Получение привилегированного доступа
к узлу.
Загрузка инструментария
злоумышленника
Инциденты неавторизованного доступа отличаются от других типов инцидентов тем, что они могут происходить в несколько этапов.
Обычно атакующие выполняют множественные разведывательные
действия, чтобы определить внутреннюю структуру сетей: идентифицировать узлы; определить, какие операционная система, услуги и
приложения установлены на каждом узле. Разведывательные действия
должны контролироваться, чтобы осознать возможный риск.
После завершения разведывательных действий атакующие начинают предпринимать действия по осуществлению неавторизованного доступа к системам. Некоторые уязвимости позволяют привилегированный доступ получить сразу, в один этап, в то время как
другие уязвимости обеспечивают только доступ на уровне пользователя. Большинство атакующих ищут доступ к системам на уровне
администратора. Они стремятся определить уязвимости, которые мо42
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
гут предоставить привилегированный доступ. Если такая уязвимость
не обнаружена или не может быть использована, атакующие могут
пытаться найти и использовать уязвимости, которые обеспечат доступ
на уровне пользователя, и затем проводить дополнительные атаки,
чтобы повысить уровень доступа. Из-за того, что этот процесс может
занять значительное время, эта атака может быть обнаружена на промежуточном этапе, когда некоторый доступ был получен, но поиск
доступа продолжается. Группа реагирования на инциденты должна
попытаться обнаружить и начать обработку таких инцидентов до того,
как будет получен полный доступ на уровне администратора.
Во время инцидентов неавторизованного доступа трудно отличить обычную активность от злоумышленной активности. Такие
указатели, как отключения компонентов систем, изменения конфигурации мониторинга, вполне вероятно являются авторизованной
деятельностью, а не атаками. Ключом к определению источника активности является процесс управления изменениями информационной сферы в организации. Если запланировано обслуживание системы, как, например, обновление операционной системы, эта информация должна доводиться персоналу, который наблюдает и анализирует предвестники и указатели. Тогда при обнаружении подозрительных указателей аналитик может определить, что они вызваны
плановой активностью обслуживания.
При установлении степени опасности инцидента неавторизованного доступа определение существующего и потенциального технического воздействия инцидента может быть очень трудным. Из-за того, что
атакующие хотят поднять привилегии доступа на уровне пользователя
до доступа на уровне администратора, текущие инциденты следует потенциально идентифицировать как доступ на системном уровне. Текущее воздействие инцидента может быть трудно определить, пока не
проведен расширенный анализ. Однако часто необходимо, чтобы опасность инцидента была определена до того, как завершится анализ. Поэтому, основываясь на оценке текущего воздействия, лучше допустить,
что инцидент неавторизованного доступа приведет к более опасным
последствиям, т.е. повысить его значимость.
2.3.2. Сдерживание инцидента неавторизованного доступа
Время реагирования на инцидент является критичным при
сдерживании инцидента неавторизованного доступа. Чтобы определить точно, что случилось, может потребоваться расширенный ана43
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
лиз; в случае активной атаки состояние системы может быстро изменяться. В большинстве случаев после выполнения начального
анализа инцидента и установления степени опасности этого инцидента целесообразно реализовать начальные меры сдерживания и затем выполнить дальнейший анализ, чтобы определить, достаточны
ли были меры сдерживания. Например, может быть не очевидно,
скопировал ли атакующий системный файл паролей. Отсоединение
узла от сети, пока обработчики инцидента определяют, был ли
скомпрометирован файл паролей, должно препятствовать атакующему использовать эти пароли. В большинстве сред, однако, это не
так. Из-за доверенных отношений между системами и пользователями, обеспечивающих одни и те же пароли или пароли для многих
систем, украденные пароли часто используются для доступа к другим системам. Инцидент может быстро расшириться от одного узла
до многих узлов за короткое время.
Обработчикам инцидентов сложно выбрать стратегии сдерживания, так как если они допускают наихудшее, то стратегия сдерживания может заблокировать все сети и системы. Обработчики инцидентов должны рассмотреть более умеренные решения, которые направлены на уменьшение риска до приемлемого уровня, чем блокирование всех сетей и систем (если конечно, степень злоумышленной
активности не так велика). Последовательность предпринимаемых
защитных мер при сдерживании инцидента неавторизованного доступа может быть такой:
– изолирование затронутых узлов и систем.
Это простейший прием по сдерживанию инцидента неавторизованного доступа – отсоединить каждую затронутую систему и узел.
Это предохраняет системы от дальнейшей компрометации. Однако
проблемой может быть идентификация всех затронутых систем.
Атакующие часто используют одну скомпрометированную систему
как источник атак против других внутренних систем. Обработчики
должны исследовать другие системы с точки зрения признаков успешных атак;
– блокирование затронутых услуг.
Если атакующий использует конкретную услугу, чтобы получить неавторизованный доступ, то сдерживание может представлять
собой временное или постоянное блокирование этой услуги. Например, если атакующий использует уязвимость FTP и неавторизован44
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ный доступ ограничивается файлами данных FTP, то инцидент может быть сдержан временным блокированием услуги FTP. Если FTP
используется для неавторизованного доступа к информационным
активам, тогда услуга FTP должна быть блокирована постоянно;
– блокирование маршрутов атакующего.
Следует препятствовать доступу атакующего к соседним активам, которые могут быть следующими целями. Примеры: блокирование входящих соединений к конкретному сегменту сети или отсоединение сервера удаленного доступа;
– блокирование учетных записей пользователя, которые могли
быть использованы при атаке.
Одни и те же учетные записи и пароли, которые были скомпрометированы в одной системе, могут работать в других системах.
Следовательно, может понадобиться блокирование этих учетных записей. Обработчики также должны определить новые учетные записи пользователя, которые могут быть созданы атакующим.
2.3.3. Устранение инцидента неавторизованного доступа
и восстановление после него
Если при устранении инцидента и восстановлении после инцидента неавторизованного доступа обработчики инцидентов предполагают, что атакующий получил доступ к системе, то нельзя доверять OC. В этом случае необходимо восстановить операционную
систему и приложения из резервной копии и затем защитить систему. Рекомендуется изменение всех паролей во всех системах, которые имели отношения с атакованной системой. Инциденты неавторизованного доступа, как правило, используют множество уязвимостей. Поэтому важно для обработчиков идентифицировать все уязвимости, которые были использованы, и определить стратегии для
их уменьшения.
Если атакующий получает меньший уровень доступа, чем уровень
администратора, то действия по устранению и восстановлению могут
соответствовать уровню, до которого атакующий получил доступ.
Должны быть выполнены действия, которые уменьшили бы риск. Например, если атакующий получил доступ на уровне пользователя путем отгадывания слабого пароля, тогда этот пароль не только должен
быть заменен более сильным паролем, но также администратор и владелец системы должны скорректировать требования к паролям, возможно, пересмотреть политики парольной защиты.
45
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
2.3.4. Сбор и обработка свидетельств инцидента
неавторизованного доступа
При сборе и обработке свидетельств (доказательств) инцидента
неавторизованного доступа и подготовке завершающего отчета необходимо зафиксировать относящиеся к этому инциденту данные,
включающие записи журналов мониторинга ИБ узлов и приложений,
предупреждения об обнаружении вторжения и журналы МСЭ. Эти
данные обеспечат доказательство инцидента неавторизованного доступа. Инциденты неавторизованного доступа чаще, чем большинство
других инцидентов, ведут к судебному разбирательству. Поэтому
важно следовать установленным процедурам сбора и обработки свидетельств для последующего расследования инцидента неавторизованного доступа.
Контрольные вопросы
1. Определение и цели инцидента неавторизованного доступа.
2. Планирование системы управления инцидентами неавторизованного доступа.
3. Подготовка к обработке инцидента.
4. Защитные меры для предотвращения инцидента неавторизованного доступа.
5. Последовательность действий при обработке инцидента неавторизованного доступа.
6. Порядок обработки инцидента неавторизованного доступа.
7. Обнаружение и анализ инцидента неавторизованного доступа.
8. Сдерживание инцидента неавторизованного доступа.
9. Устранение инцидента неавторизованного доступа и восстановление после него. Сбор и обработка свидетельств инцидента неавторизованного доступа.
46
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3. Управление инцидентами отказа в обслуживании
3.1. Определение инцидента отказа в обслуживании.
Примеры инцидентов отказа в обслуживании
Инциденты отказа в обслуживании (DoS) приводят к неспособности систем, сервисов и сетей продолжать функционирование с
прежней производительностью, чаще всего при полном отказе в доступе авторизованным пользователям, связанном с уничтожением
или истощением ресурсов. Целями инцидента отказа в обслуживании могут быть:
– снижение пропускной способности сети путем использования
всей доступной пропускной способности сети генерацией больших
объемов трафика;
– вывод из строя операционной системы передачей к серверу
неправильно оформленных пакетов TCP/IP;
– замедление работы или блокирование системы, сервиса, сети с
помощью установления многих одновременных сеансов входа в систему, к сервису, сети;
– использование всего объема памяти систем путем создания
многочисленных, больших по объему файлов.
Атаки отказа в обслуживании делятся на два вида:
1) атаки DoS:
– рефлекторные атаки;
– усилительные атаки;
2) атаки распределенного DoS.
При рефлекторной атаке узел с выдуманным адресом источника
посылает много запросов на обслуживание на промежуточный узел.
Используемая услуга обычно основана на Протоколе дейтаграмм
пользователя (UDP), который позволяет успешно имитировать адрес
источника. Атакующие часто используют имитирующие адреса источника, так как они скрывают действительный источник атаки.
Промежуточный узел генерирует ответ на каждый запрос и передает
эти ответы выдуманному адресу. Из-за того, что промежуточный
узел невольно выполняет эту атаку, то этот узел является рефлектором. Во время рефлекторной атаки отказ в обслуживании может
быть направлен к узлу с выдуманным адресом, к самому рефлектору
или к обоим узлам. Примеры общеиспользуемых услуг рефлектора
включают эхо (порт 7), загрузку (порт 19), DNS (порт 53), простой
протокол управления сетью (SNMP) (порт 161).
47
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В некоторых случаях два рефлектора могут быть использованы,
чтобы создать автономный отказ в обслуживании. Атакующий может посылать запросы к рефлектору, используя выдуманный адрес
источника другого рефлектора. Поэтому, когда первый рефлектор
генерирует свои ответы, он должен посылать их ко второму рефлектору. Если эта комбинация рефлекторов выбрана правильно, то между двумя рефлекторами возникает контур.
Большинство атак рефлектора может быть предотвращено через
множество правил МСЭ, которые отражают подозрительные комбинации портов источника и пунктов назначения.
На рис. 7 показана диаграмма рефлекторной атаки, которая использует сервер DNS. Атака может быть представлена в виде трех
этапов:
1) атакующий посылает пакет к серверу DNS. При этом он использует выдуманный адрес источника, в этом случае – j.k.l.m. Этот
пакет также использует порт седьмого источника;
2) сервер DNS принимает пакет, он генерирует и посылает ответ
к жертве по адресу j.k.l.m;
3) жертва выполняет услугу эхо, тогда узел может создать пакет,
который отражает (создает эхо) принимаемые данные назад к серверу DNS. Это может вызвать петлю (контур) между сервером DNS и
жертвой, если сервер DNS отвечает на пакеты, посланные жертвой.
Рис. 7. Рефлекторная атака, использующая сервер DNS
Подобно рефлекторной атаке, усилительная атака основана на
передаче запросов с выдуманным адресом источника к промежуточ48
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ному узлу. Однако усилительная атака не использует один промежуточный узел, ее цель – использовать целую сеть промежуточных узлов. При усилительной атаке запросы ICMP или запросы UDP передаются в широковещательном режиме с целью, что многие узлы будут отвечать на запросы. Из-за того, что запрос атакующего использует выдуманный адрес источника, все ответы посылаются по этому
ложному адресу, что может вызвать отказ в обслуживании этого узла или сети узлов. Большая часть сред блокирует усилительные атаки путем конфигурирования маршрутизаторов так, чтобы не ретранслировать направленные широковещательные рассылки.
На рис. 8 показана простая усилительная атака на базе ICMP.
Атакующий посылает запрос ответа ICMP к целевому адресу. Пакет
запроса имеет две характеристики:
– адрес IP источника пакета выдуман как j.k.l.m (адрес IP назначенной жертвы);
– адрес IP назначения пакета – w.x.y.255 является действительным адресом широковещательной рассылки.
На рис. 8 показаны два этапа атаки:
1) запрос ответа от атакующего принят сетью w.x.y;
2) произошла широковещательная рассылка к узлам w.x.y. Эта
активность генерировала многочисленные ответы на запрос, которые одновременно достигают назначенной жертвы по адресу IP
j.k.l.m. Атакующие могут послать запросы ко многим сетям одновременно так, что жертва получает большое число одновременных
ответов на запрос.
Рис. 8. Усилительная атака
49
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Пропускная способность сети является настолько высокой в
большинстве организаций, что одиночная атакующая машина не
может вызвать отказ в обслуживании сети. Однако атакующие могут
выполнять атаки распределенного отказа в обслуживании (DDoS),
при которых источником опасного трафика может быть большое
число компьютеров. Если используется достаточно узлов, то общий
объем сгенерированного трафика сети может истощить не только
ресурсы намеченного узла, но также пропускную способность сети
почти любой организации. Атаки DDoS, являющиеся причиной отсутствия доступности вычислительных и сетевых услуг, приводят к
значительным финансовым потерям.
Атаки DDoS обычно используют два типа компонентов: агенты,
которые работают на скомпрометированных узлах и выполняют
действительные атаки; и обработчик, который является программой,
управляющей агентами, и которая говорит им, когда атаковать, что
атаковать и как атаковать. Атакующие часто используют сотни или
тысячи агентов, когда выполняют атаку DDoS. На рис. 9 показаны
три этапа атаки DDoS:
1) атакующие компрометируют узлы и размещают в них агентов
DDoS;
2) атакующий использует обработчика, чтобы инструктировать
агентов DDoS о том, что атаковать, когда атаковать и как атаковать;
3) агенты следуют инструкциям и атакуют намеченные жертвы.
Рис. 9. Атака распределенного отказа в обслуживании
50
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3.2. Планирование системы управления
инцидентами отказа в обслуживании
3.2.1. Подготовка к обработке инцидента
При подготовке к обработке инцидента необходимо построить
возможные сценарии известных инцидентов отказа в обслуживании.
Сценарии развития инцидента строятся на основе критических
событий, которые приводят к инциденту, и предшествующих им нежелательных событий. В табл. 9 приведены критические события и
предшествующие им нежелательные события инцидента отказа в обслуживании.
Таблица 9
Нежелательные события инцидента отказа в обслуживании
Критическое событие
Нежелательные события
Отказ в обслуживании
конкретного узла
Недоступность узла.
Потеря соединения с узлом
Отказ в обслуживании
сети
Недоступность сети.
Потеря соединения с конкретной сетью
Отказ в обслуживании
операционной системы
узла
Недоступность операционной системы узла.
Потеря соединения с операционной системой узла
Отказ в обслуживании
приложения на узле
Недоступность приложения на узле.
Потеря соединения с приложением на узле
На рис. 10 представлены примеры сценариев развития инцидента отказа в обслуживании.
Инцидент отказа в обслуживании может привести к прерыванию одного или нескольких бизнес-процессов и потере данных, что
в свою очередь вызовет потерю производительности, материальный
ущерб и ущерб репутации.
На рис. 11 представлены примеры сценариев последствий инцидента отказа в обслуживании.
Сценарии инцидента отказа в обслуживании, сочетающие сценарии развития и последствий инцидента, представлены на рис. 12.
Данная схема позволяет проанализировать сценарии инцидента
отказа в обслуживании от вызвавших его нежелательных событий до
негативных последствий, которые он за собой повлечет.
51
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Недоступность
узла
Потеря
соединения с
узлом
Отказ в
обслуживании
конкретного
узла
Недоступность
сети
Потеря
соединения с
конкретной
сетью
Недоступность
операционной
системы узла
Потеря
соединения с
операционной
системой узла
Недоступность
приложения на
узле
Потеря
соединения с
приложением
на узле
Отказ в
обслуживании
сети
Отказ в
обслуживании
Отказ в
обслуживании
ОС узла
Отказ в
обслуживании
приложения на
узле
Рис. 10. Сценарии развития инцидента отказа в обслуживании
Рис. 11. Сценарии последствий инцидента отказа в обслуживании
52
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
53
Рис. 12. Сценарии инцидента отказа в обслуживании
53
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3.2.2. Выбор защитных мер
Защитные меры для предотвращения отказа в обслуживании сервисов, систем, узлов или сетей, выбранные на основе результатов
оценки рисков, нацелены на противодействие реализации выявленных
угроз и снижение возможности использования уязвимостей для проведения атак. Такими защитными мерами, например, могут быть:
а) конфигурирование периметра сети так, чтобы запретить весь
входящий и исходящий трафик, который не разрешен. Это должно
включать:
– блокирование использования услуг, таких как эхо и загрузка,
которые больше не служат установленной цели и используются при
атаках DoS;
– выполнение фильтрации выхода и входа, чтобы блокировать
ложные пакеты;
– формирование правил межсетевого экрана и управления доступом к маршрутизатору, позволяющих эффективно блокировать опасный трафик;
– конфигурирование пограничных маршрутизаторов таким образом, чтобы блокировалась ретрансляция направленных широковещательных рассылок;
б) ограничение скорости для определенных протоколов, таких как
ICMP, чтобы они могли использовать только определенную часть общей пропускной способности. Ограничение скорости может быть реализовано на пограничных маршрутизаторах и межсетевых экранах;
в) блокирование всех ненужных услуг и ограничение использования услуг, которые могут быть использованы при атаках DoS, на узлах, имеющих доступ в Internet;
г) обеспечение уверенности, что сети и системы не работают на
максимальной пропускной способности. В противном случае это облегчит атаку DoS.
Кроме того, по результатам оценки рисков могут быть выбраны
защитные меры, позволяющие обнаруживать трафик DoS и DDoS.
К таким защитным мерам, например, могут относиться сетевые и узловые СОВ и МСЭ.
Для обнаружения нежелательных событий инцидента отказа в обслуживании может быть использован мониторинг активов системы.
С помощью него можно, например, выявить значительное отклонение
от нормального поведения систем, определить источник использования сетевой пропускной способности и критичных активов.
54
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Однако ввиду высокого уровня остаточного риска, появления новых угроз и уязвимостей выбранных защитных мер может быть недостаточно, и инциденты кибербезопасности будут происходить. Необходима своевременная и оперативная обработка инцидента отказа в обслуживании, чтобы снизить возможный ущерб от него.
На основе анализа сценариев инцидента должны быть определены
защитные меры по сдерживанию, устранению инцидента и восстановлению после него. Эти меры выбираются и реализуются членами
ГРИИБ в соответствии со сценарием развития инцидента.
К защитным мерам, сдерживающим инцидент отказа в обслуживании, относятся:
– блокирование трафика от источника активности;
– реализация фильтрации на основе характеристик атаки.
Мерами по устранению инцидента отказа в обслуживании могут
быть, например:
– присвоение атакованному узлу другого адреса IP (маскировка
цели);
– дистанционное блокирование атакующих агентов DDoS.
В качестве мер по восстановлению после инцидента отказа в обслуживании могут служить следующие:
– идентификация всех уязвимостей, которые были использованы,
и определение стратегии для их уменьшения;
– восстановление работоспособности поврежденных аппаратных
и программных средств.
На рис. 13 представлен пример применения защитных мер в соответствии с последовательностью событий сценария инцидента отказа в обслуживании, начинающегося с события «потеря соединения
с узлом».
3.2.3. Формирование последовательности действий
при обработке инцидентов отказа в обслуживании
Для обеспечения эффективного реагирования на инцидент в организации должна быть сформирована последовательность действий при
обработке инцидентов отказа в обслуживании. Этот перечень приводится в табл. 10. Последовательность действий может меняться в зависимости от особенностей инцидентов и стратегий по сдерживанию
инцидента, выбранных конкретной организацией.
55
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. 13. Пример применения защитных мер на одном из сценариев
инцидента отказа в обслуживании
Таблица 10
Последовательность действий
при обработке инцидентов отказа в обслуживании
Действие
Завершено
Анализ инцидента отказа в обслуживании
Сбор и документирование дополнительных свидетельств
1
(доказательств) инцидента для определения его реальности
и значимости
Определение значимости инцидента с точки зрения
2
его воздействия на бизнес
2.1 Идентификация затронутых активов и прогнозирование, какие
активы могут быть затронуты
2.2 Оценивание существующих и потенциальных воздействий
инцидента
Определение по матрице значимости инцидентов условий
2.3 реагирования на основе технического воздействия
и затронутых активов
Сообщение
об инциденте соответствующему внутреннему
3
персоналу и внешним организациям
Сдерживание, устранение инцидента и восстановление после инцидента
Выполнение начального сдерживания инцидента (например,
4
фильтрация трафика, отключение услуг и т.д.).
Получение, документирование, сохранение и обеспечение
5
безопасности свидетельств (доказательств) инцидента
Устранение инцидента (идентификация и минимизация всех
6
уязвимостей, которые были использованы)
7
Восстановление после инцидента
7.1 Восстановление затронутых инцидентом систем к рабочему
состоянию
7.2 Проверка функционирования затронутых систем
7.3 Подготовка завершающего отчета
Деятельность после инцидента
56
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3.2.4. Формирование порядка обработки инцидента
отказа в обслуживании
В организации должен быть определен порядок обработки инцидентов отказа в обслуживании в зависимости от их значимости. Примерная матрица определения значимости инцидентов отказа в обслуживании показана в табл. 11.
Таблица 11
Примерная матрица определения значимости инцидентов
отказа в обслуживании
Критичность (важность) активов, затрагиваемых
в настоящее время или которые, по всей вероятности,
будут затронуты инцидентом
Существующее
Высокая (например,
воздействие или
связность с Internet, Средняя (напривероятное будущее
Низкая (наприWeb-серверы, рабомер, серверы
воздействие
мер, рабочие
чие станции систем- файлов, серверы
инцидента
станции польных и ИБ админист- печати, почтовый
зователей)
раторов, сервер
сервер)
мониторинга)
Отказ
в обслуживании
Значимость 1
Значимость 2
Значимость 3
на системном
уровне
Отказ
в обслуживании
Значимость 2
Значимость 4
Значимость 5
на уровне
пользователя
Заголовки столбцов показывают различную степень критичности
ресурсов, а заголовки строк  различные категории технического воздействия. Уровень значимости инцидента в матрице определяет приоритетность его обработки.
3.3. Использование системы управления инцидентами
отказа в обслуживании
3.3.1. Обнаружение и анализ инцидента отказа в обслуживании
Обнаружение и анализ инцидентов отказа в обслуживании может
происходить с помощью различных предвестников и указателей.
В табл. 12 перечисляются возможные предвестники атак DoS и приводятся действия, которые могут предотвратить появление инцидента.
57
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В табл. 13 перечисляются нежелательные события инцидента отказа в
обслуживании и для каждого такого действия перечисляются возможные указатели.
Таблица 12
Предвестники инцидента отказа в обслуживании
и действия по их предотвращению
Предвестник
Действия по предотвращению
Атакам DoS часто предшествует
разведывательная деятельность,
чтобы определить, какие атаки могут
быть эффективными, например,
определение объема трафика,
опасного для данной системы
Если обнаруживается активность,
которая кажется подготовкой для атаки
DoS, организация может блокировать
атаку посредством быстрого изменения
ее безопасности, например, изменение
правил сетевого экрана, чтобы
блокировать конкретный протокол
или защитить уязвимый узел
Недавно выпущенный инструмент
DoS может представить
значительную угрозу
для организации
Необходимо расследовать новый
инструмент и, если можно, изменить
средства управления безопасностью так,
чтобы этот инструмент стал
неэффективным при реализации атак
DoS на системы организации
Таблица 13
Указатели отказа в обслуживании
Возможные указатели
Нежелательные события
1
2
Сообщения пользователя
о недоступности системы, сети
или приложения
Недоступность узла.
Потеря соединения с узлом.
Недоступность сети.
Потеря соединения с конкретной сетью.
Недоступность операционной системы
узла.
Потеря соединения с операционной
системой узла.
Недоступность приложения на узле.
Потеря соединения с приложением на узле
Необъяснимые потери соединения
Недоступность узла.
Потеря соединения с узлом.
Недоступность сети.
Потеря соединения с конкретной сетью
58
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Продолжение табл 13
1
2
Предупреждения об обнаружении
вторжения в сеть
Недоступность узла.
Потеря соединения с узлом.
Недоступность сети.
Потеря соединения с конкретной сетью.
Недоступность операционной системы
узла.
Потеря соединения с операционной
системой узла.
Недоступность приложения на узле.
Потеря соединения с приложением на узле
Возросшее использование сетевой
пропускной способности
Недоступность узла.
Потеря соединения с узлом.
Недоступность сети.
Потеря соединения с конкретной сетью
Большое число соединений
к одному узлу
Недоступность узла.
Потеря соединения с узлом.
Недоступность операционной системы
узла.
Потеря соединения с операционной
системой узла
Асимметричная картина сетевого
трафика (большой объем трафика,
идущего к узлу, небольшой
трафик, выходящий из узла)
Недоступность узла.
Потеря соединения с узлом.
Недоступность сети.
Потеря соединения с конкретной сетью.
Недоступность операционной системы узла.
Потеря соединения с операционной
системой узла
Записи журнала МСЭ
и маршрутизатора
Недоступность узла.
Потеря соединения с узлом.
Недоступность сети.
Потеря соединения с конкретной сетью
Пакеты с необычными адресами
источников
Недоступность узла.
Потеря соединения с узлом.
Недоступность сети.
Потеря соединения с конкретной сетью.
Недоступность операционной системы
узла.
Потеря соединения с операционной
системой узла.
Недоступность приложения на узле.
Потеря соединения с приложением на узле
59
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Окончание табл. 13
1
Пакеты с несуществующими
адресами назначения
Записи журнала операционной
системы
Записи журнала приложения
2
Недоступность сети.
Потеря соединения с конкретной сетью
Недоступность операционной системы
узла.
Потеря соединения с операционной
системой узла
Недоступность приложения на узле.
Потеря соединения с приложением на узле
Атаки DoS создают следующие проблемы при анализе инцидентов:
– атаки DoS часто используют протоколы, неориентированные на
соединение (UDP и ICMP), или протокол, ориентированный на соединение таким способом, чтобы не устанавливать полные соединения
(например, передача пакетов TCP SYN, чтобы создать атаку затопления сигналами). Таким образом, для атакующих относительно легко
использовать выдуманные адреса IP источника, создавая трудность в
отслеживании источника атак. Является эффективным просмотр журналов предыдущей разведывательной активности. Из-за того, что атакующий должен получить результаты разведки, такая активность маловероятна с использованием ложных адресов, так что она может указывать местоположение атакующего;
– атаки DoS часто используют сотни или тысячи рабочих станций,
которые управляются (контролируются) одним (или, вообще, никаким) обработчиком. Жертва не будет видеть IP обработчика и, даже
если бы это было возможно, то это был бы, вероятно, узел, который
скомпрометировал атакующий;
– когда происходит выход из строя активов, часто можно не понять, что это вызвано атакой DoS. Например, сервер может случайно
выйти из строя как результат нестабильности операционной системы, требующей повторной загрузки для восстановления ее функционирования. Если атакующий посылает специальные пакеты к
серверу, которые вызывают его выход из строя, то системные администраторы могут предположить, что выход из строя произошел изза нестабильности операционной системы, и не осознать, что имела
место атака.
60
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3.3.2. Сдерживание, устранение инцидента отказа в обслуживании
и восстановление после него
Сдерживание, устранение инцидента отказа в обслуживании обычно
состоит в противодействии опасному трафику. Часто это противодействие состоит в блокировании всего трафика от источника активности. Однако такие атаки имеют ложные адреса источника или используют сотни
или тысячи скомпрометированных узлов, что делает трудным или невозможным реализацию эффективной фильтрации, основанной на адресах
IP. Даже если организация может блокировать адреса источников, которые используются, атакующий может перейти к другим адресам IP. Действия по сдерживанию, устранению инцидента отказа в обслуживании, а
также восстановлению после инцидента отказа в обслуживании таковы:
– уменьшение уязвимостей, которые используются. Например,
если атака может произойти из-за того, что МСЭ не блокируют пакеты, использующие порт 7 UDP (эхо) и публично доступный узел выполняет услугу эхо, то МСЭ должны быть скорректированы, чтобы
блокировать пакеты, назначенные для порта эхо; и конфигурация узла
должна быть так изменена, чтобы он больше не предлагал услугу эхо.
Если операционная система узла не устойчива к атакам DoS, то она
должна быть скорректирована. Этот узел, возможно, надо будет отсоединить от сети, чтобы остановить атаку DoS, пока корректируется
операционная система узла;
– реализация фильтрации на основе характеристик атаки. Например, если атака использует запросы эхо ICMP, то можно временно блокировать такие запросы от входа в сеть. К сожалению, это не всегда практично: если атакующий посылает поток пакетов SYN к порту протокола
гипертекстовой передачи (HTTP) Web-сервера, то блокирование пакетов
SYN, назначенных для этого порта, будет само вызывать отказ в обслуживании для пользователей. Другая стратегия состоит в ограничении
скорости, позволяя только определенное число пакетов в секунду для
использования специфичного протокола или контакта с определенным
узлом. Хотя приемы фильтрации могут быть эффективны при сдерживании инцидентов, они могут вносить дополнительные проблемы. Например, добавление новых правил к маршрутизатору или межсетевому экрану может иметь существенное негативное воздействие на работу (характеристики) устройств, вызывая снижение пропускной способности сети;
– маскировка цели. Если целью является конкретный узел и другие
стратегии сдерживания не работают, то узлу может быть присвоен другой
адрес IP. Если целью является конкретная услуга узла, то услуга может
быть передана другому узлу – узлу без соответствующей уязвимости;
61
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
– атака атакующих. Например, администраторы могут использовать программы, которые позволяют дистанционно блокировать атакующих агентов DDoS, или они (программы) могут модифицировать
конфигурацию сети или сервера, чтобы перенаправить опасный трафик
назад к источнику атаки. Однако если адрес источника ложный или адрес источника законный, но находится в совместном владении, то эти
приемы могут ненамеренно атаковать невинную сторону. Такие приемы
hack back (хакерство назад) должны использоваться очень осторожно.
3.3.3. Сбор и обработка свидетельств инцидента отказа
в обслуживании
Сбор и обработка свидетельств (доказательств) инцидента отказа
в обслуживании часто являются проблемным и затратным делом по
времени из-за следующих причин:
– сложность идентификации источника атак из наблюдаемого трафика. Адреса источника IP часто модифицированы. Атаки DDoS могут
использовать сотни и тысячи узлов, каждый из которых может использовать множество ложных адресов;
– сложность изучения того, как были скомпрометированы атакующие узлы. При атаках DDoS узлы агентов могут быть скомпрометированы. Атакующий может даже не быть ответственным за компрометацию; атакующий просто использует узлы, которые ранее были
скомпрометированы другими;
– сложность просмотра большого числа записей журнала мониторинга. Большинство атак DoS генерирует большой трафик и при мониторинге систем в журналах фиксируется большое число записей. Для обзора записей и выделения полезной информации требуется много времени.
Контрольные вопросы
1. Определение инцидента отказа в обслуживании. Примеры инцидентов отказа в обслуживании.
2. Подготовка к обработке инцидента.
3. Защитные меры для предотвращения инцидентов отказа в обслуживании.
4. Последовательность действий при обработке инцидентов отказа
в обслуживании.
5. Порядок обработки инцидента отказа в обслуживании.
6. Обнаружение и анализ инцидента отказа в обслуживании.
7. Сдерживание, устранение инцидента отказа в обслуживании и
восстановление после него.
8. Сбор и обработка свидетельств инцидента отказа в обслуживании.
62
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
4. Управление инцидентами внедрения
вредоносного кода
4.1. Определение инцидента внедрения вредоносного кода.
Примеры атак, связанных с внедрением
вредоносного кода
Вредоносный код представляет собой программу, скрытно введенную в другую программу с намерением уничтожить данные, выполнить разрушительные или «навязчивые» программы или какимлибо иным образом скомпрометировать безопасность или целостность
данных «жертвы». В основном вредоносный код предназначается для
выполнения данных неблаговидных функций, при этом нет необходимости знать пользователя системы.
Атаки, связанные с использованием вредоносного кода, могут
быть разделены на пять категорий: вирусы, «троянские кони», «черви»
и мобильный код.
Вирус обладает способностью к самокопированию, созданию собственных копий и распространению копий в другие файлы, программы
или компьютеры. Вирусы внедряются в программы узла и распространяются во время исполнения инфицированной программы, обычно при
участии пользователя (например, открытие файла, выполнение программы, щелчок мыши на файловом дополнении).
Файловые вирусы причисляются к исполняемым программам,
таким как текстовые процессоры, приложения и компьютерные игры. Инфицировав программу, они распространяются, чтобы инфицировать и другие программы в данной системе и в других системах,
которые используют разделяемую (совместно используемую) инфицированную программу. Такой вирус может также постоянно храниться в памяти системы, поэтому каждый раз, когда выполняется
новая программа, он заражает эту программу. Другой метод исполнения файловых вирусов связан с использованием вируса, модифицирующего способ (манеру), которым компьютер открывает файл, а
не с модификацией фактической программы, исполняющей этот
файл. При таком сценарии сначала исполняется вирус, а затем исполняется программа. Jerusalem и Cascade являются примерами файловых вирусов.
63
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Вирусы загрузочного сектора инфицируют главную загрузочную запись (master boot record – MBR) жесткого диска или загрузочного сектора сменных носителей, например, гибких дисков. Загрузочный сектор является областью в начале накопителя или диска,
где хранится информация о его структуре. Загрузочные секторы содержат программы загрузки, которые выполняются при запуске,
чтобы загрузить операционную систему. MBR жесткого диска является единственным местом на диске, где может располагаться основная система ввода/вывода (BIOS) и загружаться программа загрузки. Сменные носители, например, гибкие диски не должны быть
загрузочными, чтобы не заразить систему; если инфицированный
диск находится в накопителе, когда компьютер загружается, то вирус может исполняться. Вирусы загрузочного сектора легко маскируемы, имеют высокий процент успеха и могут причинить вред
компьютеру до степени полной неработоспособности. Симптомы
инфицирования вирусом загрузочного сектора следующие: компьютер отображает сообщение об ошибке во время загрузки или не может загрузиться. Form, Michelangelo и Stoned являются примерами
вирусов загрузочного сектора.
Макровирусы – наиболее распространенный и успешный тип
вируса. Макровирусы присоединяются к документам, таким как
файлы обработки текстов и крупноформатные таблицы. Как видно
из названия, макровирусы используют для собственного исполнения
и распространения макроязык программирования приложений. Многие популярные пакеты программного обеспечения, такие как Microsoft Office, используют макроязыки программирования в своих
продуктах, чтобы автоматизировать сложные или повторяющиеся
задачи. Атакующие используют возможности макропрограммирования, чтобы распространять вредоносный код. Макровирусы имеют
тенденцию быстро распространяться по причине того, что пользователи часто совместно используют документы из приложений
с макровозможностями. Более того, когда происходит инфицирование макровирусом, вирус также заражает шаблон, который
использует программа, чтобы создавать и открывать файлы. Следовательно, каждый документ, который создается или открывается
с помощью инфицированного шаблона, также инфицируется. Вирусы Concept, Marker и Melissa являются примерами макровирусов.
Вирусные мистификации являются ложными предупреждениями
о вирусе. Ложные вирусы обычно описываются как вирусы огромной
64
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
величины, требующие незамедлительного действия, чтобы адекватно
защитить компьютерные ресурсы от инфицирования. Несмотря на некорректность таких сообщений, вирусные мистификации являются такими же распространенными в цифровом мире, как и действительные
вирусы. Вирусные мистификации распространяются неискушенными
конечными пользователями, которые уверены, что они помогают распространению этих предупреждений для Internet-сообщества. Мистификации обычно наносят незначительный вред, хотя некоторые вредоносные вирусные мистификации предписывают пользователям изменить установки операционной системы или удалить файлы, что может привести к проблемам с безопасностью и операционным проблемам. Вирусные мистификации могут занимать время, так как многие
из получателей мистификации могут обращаться к персоналу технической поддержки, чтобы предупредить его о новой угрозе или запросить указания, что нужно делать. Примерами вирусных мистификаций
являются Good Times и Bud Frogs.
«Троянские кони», названные так в память о деревянном коне из
греческой мифологии, являются программами, которые производят
впечатление полезных, но в действительности имеют скрытую вредоносную цель. Некоторые «троянские кони» полностью замещают существующий файл в системе вредоносной версией, в то время как
другие «троянские кони» представляются одной сущностью (например, игрой, доступной для загрузки), но реально являются другой
(например, игрой и анализатором пароля). «Троянские кони» зачастую трудны для обнаружения, поскольку кажется, что они выполняют полезную функцию. «Троянских коней» можно отнести к одной из
трех моделей:
– продолжение выполнения функции первоначальной программы
и дополнительное выполнение самостоятельной вредоносной деятельности;
– продолжение выполнения функции первоначальной программы,
но модифицирование этой функции, чтобы выполнять вредоносную
деятельность (например, версия «троянского коня» программы регистрации входа, которая собирает пароли) или маскировать другую
вредоносную деятельность (например, версия «троянского коня» программы отображения процессов, которая скрывает определенные процессы, являющиеся вредоносными);
– выполнение вредоносной функции, которая полностью замещает функцию первоначальной программы.
65
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Цель большинства «троянских коней» состоит в том, чтобы дать
возможность удаленному пользователю получить доступ и полный
контроль над компьютером «жертвы». Для выполнения этого необходимо, чтобы «троянские кони» состояли из компонента клиента и компонента сервера. Клиент постоянно находится на удаленном компьютере нарушителя и старается установить соединение с сервером, который находится на инфицированном узле. Когда устанавливается соединение между клиентом и сервером, удаленный нарушитель может
выполнить команды на инфицированном компьютере и передать или
модифицировать файлы. Другая общая цель «троянских коней» состоит в том, чтобы действовать как агенты DDoS.
«Черви» – это самокопирующиеся программы, которые являются
полностью автономными, что означает, что им не требуется программа узла, чтобы инфицировать жертву. «Черви» распространяются самостоятельно; в отличие от вирусов, они могут создавать полностью
функциональные копии и самоисполняться без вмешательства пользователя. Природа «червей» позволяет им быстро распространяться.
Примерами могут служить «червь» Blaster и «червь» SQL Slammer.
Особенностью «червей» является то, что они не несут в себе никакой
вредоносной нагрузки, кроме саморазмножения, целью которого является замусоривание памяти и, как следствие, замедление работы операционной системы.
Мобильный код является программным обеспечением, которое передается из удаленной системы в локальную систему, а затем исполняется на локальной системе без точных инструкций пользователей.
Мобильный код часто действует как механизм передачи вируса 
«червя» или «троянского коня»  к рабочей станции пользователя.
Средствами передачи мобильного кода являются апплеты Java;
ActiveX, JavaScript и VBScript.
4.2. Планирование системы управления инцидентами
внедрения вредоносного кода
4.2.1. Подготовка к обработке инцидента
При подготовке к обработке инцидента необходимо построить
возможные сценарии известных инцидентов внедрения вредоносного
кода.
В табл. 14 приведены критические события и связанные с ними
нежелательные события.
66
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Таблица 14
Нежелательные события инцидента внедрения вредоносного кода
Критическое
Нежелательные события
событие
1
2
Изменения в шаблонах документов текстовой
обработки, крупноформатных таблиц и т.д.
Недоступность файлов
Удаление или разрушение файлов.
Нарушения в работе ПО.
Компрометация корня узла:
– использование узла для атаки других систем;
– нарушение работоспособности узла;
– модификация или дополнение процессов/услуг;
Вирус
– модификация критичных файлов, программ,
библиотек системы и файлов конфигурации;
– получение привилегированного доступа к узлу.
Нестабильность или отказ системы.
Выполнение неизвестных процессов.
Недоступность услуг.
Вирусная мистификация:
– навязывание ложной информации о состоянии системы;
– внушение чувства тревоги, паники пользователям;
– раздражение пользователей
Недоступность файлов.
Нарушения в работе ПО.
Компрометация корня узла:
– использование узла для атаки других систем;
– нарушение работоспособности узла;
«Червь»
– модификация или дополнение процессов/услуг;
– модификация критичных файлов, программ,
библиотек системы и файлов конфигурации;
– получение привилегированного доступа к узлу.
Нестабильность или отказ системы
Компрометация корня узла:
– использование узла для атаки других систем;
– нарушение работоспособности узла;
– модификация или дополнение процессов/услуг;
– модификация критичных файлов, программ,
«Троянский конь»
библиотек системы и файлов конфигурации;
– получение привилегированного доступа к узлу.
Выполнение неизвестных процессов, таких как
передача данных об атакуемой системе на удаленный
узел и действия, направленные на отказ
в обслуживании конкретного узла
67
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Окончание табл.14
1
Вредоносный
мобильный код
2
Изменения в шаблонах документов текстовой
обработки, крупноформатных таблиц и т.д.
Недоступность файлов.
Удаление или разрушение файлов.
Нарушения в работе ПО.
Нестабильность или отказ системы.
Выполнение неизвестных процессов.
Недоступность услуг
На рис. 14 представлены примеры сценариев развития инцидента
внедрения вредоносного кода.
Рис. 14. Сценарии развития инцидента внедрения вредоносного кода
Инцидент внедрения вредоносного кода может привести к раскрытию конфиденциальной информации, хищению интеллектуальной
собственности, хранимой в электронной форме, что повлечет за собой
денежные потери и ущерб репутации. Также инцидент внедрения вре68
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
доносного кода может привести к прерыванию одного или нескольких
бизнес-процессов и потере данных, увеличению времени на выполнение задач в системе, ошибкам пользователей, что в свою очередь вызовет потерю производительности, вследствие чего организации будет
нанесен материальный ущерб и ущерб репутации.
На рис. 15 представлены примеры сценариев последствий инцидента внедрения вредоносного кода.
Рис. 15. Сценарии последствий инцидента внедрения вредоносного кода
Сценарии инцидента внедрения вредоносного кода, сочетающие
сценарии развития и последствий инцидента внедрения вредоносного
кода, представлены на рис. 16.
Данная схема позволяет проанализировать сценарии инцидента
внедрения вредоносного кода от вызвавших его нежелательных событий до негативных последствий, которые он за собой повлечет.
69
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
«Червь»
70
«Троянский
конь»
Рис. 16. Сценарии инцидента внедрения вредоносного кода
70
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
4.2.2. Выбор защитных мер
Защитные меры для предотвращения внедрения вредоносного
кода, выбранные на основе результатов оценки рисков, нацелены на
противодействие реализации выявленных угроз и снижение возможности использования уязвимостей для проведения атак. Такими защитными мерами, например, могут быть:
– использование антивирусного программного обеспечения;
– обеспечение осведомленности пользователей о проблемах, связанных с внедрением вредоносного кода;
– обучение пользователей безопасной обработке вложений e-mail;
– применение на критичных узлах централизованных систем
обнаружения вторжения;
– конфигурация серверов и клиентов e-mail, направленная на
блокировку подозрительных файлов;
– ограничение использования неосновных программ со способностями передачи файла;
– использование установок безопасности Web-браузеров (систем
просмотра), чтобы ограничить распространение мобильного кода.
Кроме того, по результатам оценки рисков могут быть выбраны
защитные меры, позволяющие обнаруживать инциденты внедрения
вредоносного кода. К таким защитным мерам, например, могут относиться средства мониторинга ИБ организации.
Ввиду высокого уровня остаточного риска, появления новых
угроз и уязвимостей выбранных защитных мер может быть недостаточно, и инциденты кибербезопасности будут происходить. Необходима своевременная и оперативная обработка инцидентов кибербезопасности, чтобы снизить возможный ущерб от них.
На основе анализа сценариев инцидента должны быть определены защитные меры по сдерживанию, устранению инцидента и
восстановлению после него. Эти меры выбираются и реализуются
членами ГРИИБ в соответствии со сценарием развития инцидента.
К защитным мерам, сдерживающим инцидент внедрения вредоносного кода, относятся:
– предотвращение распространения вредоносного кода на другие системы;
– получение от поставщика обновленных антивирусных сигнатур для обработки нового вредоносного кода;
71
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
– конфигурирование серверов и клиентов e-mail с целью блокирования сообщений e-mail;
– блокирование конкретных узлов;
– отключение серверов e-mail;
– изолирование сетей от Internet.
Мерами по устранению инцидента и восстановлению после инцидента внедрения вредоносного кода могут быть:
– выявление и изолирование инфицированных узлов;
– обновление антивирусных сигнатур;
– передача неизвестного вредоносного кода поставщикам антивирусов;
– восстановление из резервных копий поврежденных файлов;
– изменение всех паролей во всех системах;
– идентификация уязвимостей, которые были использованы, и
определение стратегии для их уменьшения.
На рис. 17 представлен пример применения защитных мер в соответствии с последовательностью событий сценария инцидента
внедрения вредоносного кода, начинающегося с события «передача
данных об атакуемой системе на удаленный узел».
«Троянский
конь»
Рис. 17. Пример применения защитных мер на одном из сценариев
инцидента внедрения вредоносного кода
4.2.3. Формирование последовательности действий
при обработке инцидентов внедрения вредоносного кода
Для обеспечения эффективного реагирования на инцидент в организации должна быть сформирована последовательность действий
при обработке инцидентов внедрения вредоносного кода. Эта после72
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
довательность приводится в табл. 15. Последовательность шагов
(этапов) может меняться в зависимости от особенностей инцидентов
и стратегий по сдерживанию инцидента, выбранных конкретной организацией.
1
2
2.1
2.2
2.3
3
4
4.1
4.2
4.3
4.4
5
5.1
5.2
6
6.1
6.2
7
Таблица 15
Контрольный перечень действий по обработке инцидента
внедрения вредоносного кода
ЗаверДействие
шено
Анализ инцидента внедрения вредоносного кода
Сбор и документирование дополнительных свидетельств
(доказательств) инцидента для определения его реальности
и значимости
Определение значимости инцидента с точки зрения его
воздействия на бизнес
Идентификация затронутых активов и прогнозирование, какие
активы могут быть затронуты
Оценивание существующих и потенциальных воздействий
инцидента
Определение по матрице значимости инцидентов условий
реагирования на основе технического воздействия и затронутых
активов
Сообщение об инциденте соответствующему внутреннему
персоналу и внешним организациям
Сдерживание, устранение и восстановление
Сдерживание инцидента
Выявление инфицированных систем
Отключение инфицированных систем от сети
Анализ и снижение уязвимостей, которые были использованы
вредоносным кодом
Блокировка механизмов передачи вредоносного кода
при необходимости
Устранение инцидента
Удаление компонентов инцидента
Снижение используемых уязвимостей в отношении других
узлов организации
Восстановление после инцидента
Восстановление затронутых инцидентом систем в рабочее
состояние
Проверка функционирования затронутых систем
Подготовка завершающего отчета
Деятельность после инцидента
73
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
4.2.4. Формирование порядка обработки инцидента
внедрения вредоносного кода
В организации должен быть определен порядок обработки инцидентов внедрения вредоносного кода в зависимости от их значимости. Примерная матрица определения значимости инцидентов
внедрения вредоносного кода показана в табл. 16.
Таблица 16
Примерная матрица определения значимости инцидентов
внедрения вредоносного кода
Критичность (важность) активов, затрагиваемых
в настоящее время или которые, по всей вероятности,
будут затронуты инцидентом
Существующее
Высокая (напривоздействие
мер, связность
Средняя
или вероятное
Низкая
с Internet, Web(например,
будущее
(например,
серверы, рабочие
серверы файлов,
воздействие
рабочие
станции системных серверы печати,
инцидента
станции
и ИБ администрапочтовый
пользователей)
сервер)
торов, сервер
мониторинга)
Воздействие
вредоносного кода
на системном
уровне
Значимость 1
Значимость 2
Значимость 3
Воздействие
вредоносного кода
на чувствительные
данные
Значимость 1
Значимость 3
Значимость 3
Воздействие
вредоносного кода
на уровне
пользователя
Значимость 2
Значимость 4
Значимость 4
Раздражение
(приставание)
Значимость 1
Значимость 5
Значимость 5
Заголовки столбцов показывают различную степень критичности активов, а заголовки строк  различные категории технического
воздействия. Уровень значимости инцидента внедрения вредоносного кода в матрице определяет приоритетность его обработки.
74
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
4.3. Использование системы управления инцидентами
внедрения вредоносного кода
4.3.1. Обнаружение и анализ инцидента внедрения
вредоносного кода
Поскольку инциденты, связанные с использованием вредоносного кода, могут принимать различные формы, они могут быть обнаружены посредством ряда предвестников и указателей. В табл. 17
перечисляются возможные предвестники атаки внедрения вредоносного кода и приводятся действия, которые могут предотвратить появление инцидента.
Таблица 17
Предвестники инцидента внедрения вредоносного кода
Предвестники
Реагирование
Необходимо исследовать новый вирус, чтобы
определить, является ли он реальностью
или мистификацией. Это может быть сделано
посредством Web-сайтов поставщика антивируса
и сайтов, содержащих вирусные мистификации.
Если вредоносный код подтверждается
как аутентичный, понадобится обеспечить
уверенность в том, что антивирусное программное
Система оповещения
обеспечение обновляется сигнатурами вирусов
предупреждает о новом
вредоносном коде, который
в отношении нового вредоносного кода. Если
нацелен на программное
сигнатура вируса пока недоступна (отсутствует),
обеспечение, используемое
а угроза является серьезной и неотвратимой, такая
организацией
деятельность может быть блокирована другими
средствами, такими как конфигурирование
серверов или клиентов e-mail с целью
заблокировать сообщение e-mail, совпадающее
по характеристикам с новым вредоносным
кодом. Группа реагирования может также
пожелать оповестить о новом вирусе
поставщиков антивируса
Необходимо определить, каким образом
вредоносный код был введен в систему и какую
Антивирусное программное
уязвимость или недостаток он пытался использообеспечение обнаруживает и
вать. Если вредоносный код может представлять
успешно «дезинфицирует»
значительный риск для других пользователей и
или «отправляет
узлов, понадобится уменьшить недостатки,
на карантин» вновь
которые были использованы вредоносным
полученный
кодом, чтобы достичь системы, и которые
инфицированный файл
были бы использованы, чтобы инфицировать
целевой узел
75
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Указатели нежелательных событий, определенных в сценариях
инцидента (см. табл. 17), могут быть выявлены с помощью:
– сообщений сетевых и узловых СОВ;
– просмотра журналов мониторинга ИБ;
– сообщения пользователей об отклонениях в работе систем.
Указатели нежелательных событий инцидента внедрения вредоносного кода приведены в табл. 18.
Таблица 18
Указатели инцидента внедрения вредоносного кода
Возможные указатели
Нежелательные события
1
2
Изменения в шаблонах документов текстовой обработки, крупноформатных таблиц и т.д.
Недоступность файлов.
Удаление или разрушение файлов.
Нарушения в работе ПО.
Компрометация корня узла:
– использование узла для атаки других систем;
– нарушение работоспособности узла;
Антивирусное
– модификация или дополнение процессов/услуг;
программное обеспечение
– модификация критичных файлов, программ,
оповещает
библиотек системы и файлов конфигурации;
об инфицированных
– получение привилегированного доступа к узлу.
файлах
Нестабильность или отказ системы.
Выполнение неизвестных процессов.
Недоступность услуг.
Вирусная мистификация:
– навязывание ложной информации о состоянии
системы;
– внушение чувства тревоги, паники пользователям;
– раздражение пользователей
Компрометация корня узла:
– использование узла для атаки других систем;
– нарушение работоспособности узла;
– модификация критичных файлов, программ,
Антивирусное
библиотек системы и файлов конфигурации;
программное обеспечение
– модификация или дополнение процессов/услуг;
оповещает о версиях
– получение привилегированного доступа к узлу.
файлов, инфицированных
Выполнение
неизвестных процессов:
«троянским конем»
– передача данных об атакуемой системе
на удаленный узел;
– действия, направленные на отказ в обслуживании
конкретного узла
76
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Продолжение табл.18
1
Неожиданный рост
количества
передаваемых
и принимаемых
сообщений e-mail
2
Недоступность файлов.
Нарушения в работе ПО.
Компрометация корня узла:
– использование узла для атаки других систем;
– нарушение работоспособности узла;
– модификация или дополнение процессов/услуг;
– модификация критичных файлов, программ,
библиотек системы и файлов конфигурации;
– получение привилегированного доступа к узлу.
Нестабильность или отказ системы.
Выполнение неизвестных процессов, таких как
передача данных об атакуемой системе
на удаленный узел и действия, направленные
на отказ в обслуживании конкретного узла
Изменения в шаблонах документов текстовой
обработки, крупноформатных таблиц и т.д.
Недоступность файлов.
Удаление или разрушение файлов.
Нарушения в работе ПО.
Компрометация корня узла:
Сообщения пользователей
– использование узла для атаки других систем;
об изменениях
– нарушение работоспособности узла;
в шаблонах для документов
– модификация или дополнение процессов/ услуг;
текстовой обработки
– модификация критичных файлов, программ,
библиотек системы и файлов конфигурации;
– получение привилегированного доступа к узлу.
Нестабильность или отказ системы.
Выполнение неизвестных процессов.
Недоступность услуг
Изменения в шаблонах документов текстовой
обработки, крупноформатных таблиц и т.д.
Недоступность файлов.
Удаление или разрушение файлов.
Нарушения в работе ПО.
Сообщения
Компрометация корня узла:
пользователей
– использование узла для атаки других систем;
об удалении, разрушении
– нарушение работоспособности узла;
или недоступности
– модификация или дополнение процессов/ услуг;
файлов
– модификация критичных файлов, программ,
библиотек системы и файлов конфигурации;
– получение привилегированного доступа к узлу.
Нестабильность или отказ системы.
Недоступность услуг
77
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Продолжение табл. 18
1
Необычные элементы
на экране, такие как
необычные сообщения
и графики
Сообщения пользователей
о медленном старте
и выполнении программ,
нестабильности и полном
отказе системы
Сканирования порта
и безуспешные попытки
соединения, нацеленные
на уязвимую услугу
(например, открытые
ресурсы общего
пользования Windows,
HTTP)
Возросшее
использование сети
2
Нарушения в работе ПО.
Нестабильность или отказ системы.
Выполнение неизвестных процессов.
Недоступность услуг.
Вирусная мистификация:
– навязывание ложной информации о состоянии
системы;
– внушение чувства тревоги, паники пользователям;
– раздражение пользователей
Недоступность файлов.
Удаление или разрушение файлов.
Нарушения в работе ПО.
Компрометация корня узла:
– использование узла для атаки других систем;
– нарушение работоспособности узла;
– модификация или дополнение процессов/ услуг;
– модификация критичных файлов, программ,
библиотек системы и файлов конфигурации;
– получение привилегированного доступа к узлу.
Нестабильность или отказ системы.
Выполнение неизвестных процессов, таких как
передача данных об атакуемой системе
на удаленный узел и действия, направленные
на отказ в обслуживании конкретного узла.
Недоступность услуг
Выполнение неизвестных процессов, таких как
передача данных об атакуемой системе
на удаленный узел, и действия, направленные
на отказ в обслуживании конкретного узла
Нарушения в работе ПО.
Компрометация корня узла:
– использование узла для атаки других систем;
– нарушение работоспособности узла;
– модификация или дополнение процессов/ услуг;
– модификация критичных файлов, программ,
библиотек системы и файлов конфигурации;
– получение привилегированного доступа к узлу.
Нестабильность или отказ системы.
Недоступность услуг.
Выполнение неизвестных процессов, таких как
передача данных об атакуемой системе
на удаленный узел и действия, направленные
на отказ в обслуживании конкретного узла
78
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Продолжение табл.18
1
2
Компрометация корня узла:
– использование узла для атаки других систем;
– нарушение работоспособности узла;
– модификация или дополнение процессов/
услуг;
Система обнаружения
– модификация критичных файлов, программ,
вторжения в сеть оповещает
библиотек
системы и файлов конфигурации;
о передаче «троянского
– получение привилегированного доступа
коня» при взаимодействии
к узлу.
клиентсервер
Выполнение неизвестных процессов, таких как
передача данных об атакуемой системе
на удаленный узел и действия, направленные
на отказ в обслуживании конкретного узла
Записи в журналах
регистрации межсетевого
экрана и маршрутизатора
о передаче «троянского
коня»
Компрометация корня узла:
– использование узла для атаки других систем;
– нарушение работоспособности узла;
– модификация или дополнение процессов/
услуг;
– модификация критичных файлов, программ,
библиотек системы и файлов конфигурации;
– получение привилегированного доступа
к узлу.
Нестабильность или отказ системы.
Выполнение неизвестных процессов, таких как
передача данных об атакуемой системе
на удаленный узел и действия, направленные
на отказ в обслуживании конкретного узла
Сетевые соединения
между узлом
и неизвестными
удаленными системами
Компрометация корня узла:
– использование узла для атаки других
систем;
– нарушение работоспособности узла;
– модификация или дополнение процессов/
услуг;
– модификация критичных файлов, программ,
библиотек системы и файлов конфигурации;
– получение привилегированного доступа
к узлу.
Нестабильность или отказ системы.
Выполнение неизвестных процессов, таких как
передача данных об атакуемой системе
на удаленный узел и действия, направленные
на отказ в обслуживании конкретного узла
79
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Окончание табл. 18
1
2
Компрометация корня узла:
– использование узла для атаки других систем;
– нарушение работоспособности узла;
– модификация или дополнение процессов/
услуг;
– модификация критичных файлов, программ,
Необычное и неожиданное библиотек системы и файлов конфигурации;
– получение привилегированного доступа
открытие портов
к узлу.
Нестабильность или отказ системы.
Выполнение неизвестных процессов, таких
как передача данных об атакуемой системе
на удаленный узел и действия, направленные
на отказ в обслуживании конкретного узла
Передача данных об атакуемой системе
на удаленный узел.
Действия, направленные на отказ в обслуживании
конкретного узла.
Нарушения в работе ПО.
Компрометация корня узла:
– использование узла для атаки других систем;
Записи журнала
– нарушение работоспособности узла;
мониторинга ИБ
о выполнении неизвестных
– модификация или дополнение процессов/
процессов
услуг;
– модификация критичных файлов, программ,
библиотек системы и файлов конфигурации;
– получение привилегированного доступа
к узлу.
Нестабильность или отказ системы.
Недоступность услуг
Недоступность файлов.
Удаление или разрушение файлов.
Нарушения в работе ПО.
Неожиданные диалоговые
Нестабильность или отказ системы.
окна, требующие
Выполнение неизвестных процессов.
разрешения что-то сделать,
Недоступность услуг.
неожиданная графика, такая
Вирусная мистификация:
как перекрывающиеся
– навязывание ложной информации о состоянии
или перекрытые окна
системы;
сообщений
– внушение чувства тревоги, паники
пользователям;
– раздражение пользователей
80
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
4.3.2. Сдерживание и устранение инцидента внедрения
вредоносного кода
По причине того, что вредоносный код действует скрытно и может быстро распространяться на другие системы, необходимо заблаговременное сдерживание инцидента, связанного с внедрением вредоносного кода, чтобы пресечь его распространение и нанесение ущерба.
Если инфицированная система не является критической, рекомендуется отключить ее от сети немедленно. Если система выполняет критические функции, ей следует оставаться в сети только в том случае, если ущерб, который будет нанесен организации в результате недоступности услуг, будет больше, чем риски безопасности, создаваемые невыполнением немедленного отключения (отсоединения) этой системы.
Другие действия, выполнение которых может потребоваться
при сдерживании инцидента, связанного с внедрением вредоносного
кода, изложены ниже:
– предотвращение распространения вредоносного кода на другие системы.
Должны выполняться следующие процедуры:
– обеспечение осведомленности пользователей о проблемах, связанных с использованием вредоносного кода. Такая информация
должна включать в себя основной анализ методов, которые вредоносный код используют для распространения, и симптомы инфицирований. Проведение регулярных учебных занятий с пользователями помогает обеспечить уверенность в том, что пользователи осведомлены
о рисках, которые создает вредоносный код. Пользователи должны
быть также проинструктированы о том, что они должны делать, если
происходит инфицирование (например, отключить рабочую станцию
от сети, вызвать службу помощи), поскольку неправильная обработка
«инфекции» может усугубить даже незначительный инцидент;
– чтение бюллетеней поставщиков антивируса. Пользователи
могут воспользоваться списками рассылки, выпускаемыми поставщиками антивирусного программного обеспечения, которые обеспечивают своевременную информацию о новых угрозах, которые несет с собой вредоносный код;
– применение на критичных узлах централизованных систем обнаружения вторжения. СОВ может обнаружить признаки инцидентов,
связанных с использованием вредоносного кода, такие как изменения
конфигурации и модификации исполняемой системы. Программы проверки целостности файлов являются полезными при идентификации
затронутых компонентов системы;
– выявление и изолирование других инфицированных узлов.
81
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Антивирусные предупредительные сообщения являются полезным источником информации, но не каждая «инфекция» может быть
обнаружена антивирусным программным обеспечением. Обработчики инцидентов могут столкнуться с необходимостью поиска указателей инфицирования другими средствами, такими как:
– выполнение сканирований портов, чтобы обнаружить узлы,
работающие с программой «троянского коня» или неизвестным (потайным) портом;
– использование антивирусных инструментальных средств сканирования и очистки, предназначенных для борьбы с конкретными
видами вредоносного кода;
– просмотр журналов регистрации из серверов e-mail, межсетевых экранов и других систем, через которые может пройти вредоносный код, а также журналов регистрации отдельных узлов;
– конфигурирование программного обеспечения по обнаружению вторжения в сеть и узел для выявления деятельности, связанной
с инфицированием;
– проведение аудита процессов, проходящих в системах, с целью подтверждения, что все они являются корректными;
– передача неизвестного вредоносного кода поставщикам антивирусов.
Изредка вредоносный код, который не может быть точно идентифицирован антивирусным программным обеспечением, внедряется
в среду. Устранение вредоносного кода из систем и предотвращение
дополнительного инфицирования может быть затруднено или невозможно без получения от поставщика обновленных антивирусных сигнатур. Обработчики инцидентов должны быть знакомы с процедурами
предоставления на рассмотрение копий неизвестного вредоносного
кода поставщикам антивирусов организации;
– конфигурирование серверов и клиентов e-mail с целью блокирования сообщений e-mail.
Многие программы e-mail могут конфигурироваться вручную с
целью блокирования сообщений e-mail посредством конкретных
субъектов, имен вложений или других критериев, которые соответствуют данному вредоносному коду. Такое конфигурирование не
является ни решением проблемы защиты от случайных ошибок, ни
эффективным решением, но оно может быть лучшим вариантом, который возможен, если существует неминуемая угроза, а антивирусные сигнатуры еще недоступны;
– блокирование конкретных узлов.
82
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Например, если вредоносный код пытается генерировать исходящие сообщения e-mail или соединения, обработчики должны рассмотреть возможность блокирования доступа к IP адресам или услугам, к которым инфицированная система может пытаться подключиться. Кроме того, если инфицированные узлы внутри организации
будут пытаться распространить инфекцию дальше, организация может пожелать блокировать сетевой трафик от IP адресов этого узла,
чтобы контролировать ситуацию, в то время как инфицированные
узлы будут физически локализованы и «дезинфицированы»;
– отключение серверов e-mail.
При наиболее значимых инцидентах внедрения вредоносного
кода, когда инфицируются сотни или тысячи внутренних узлов, серверы e-mail могут полностью переполниться вирусами, пытающимися распространиться через e-mail. Может оказаться необходимым
отключить некий сервер e-mail, чтобы остановить распространение
вирусов, порожденных e-mail. В некоторых случаях ГРИИБ может
обнаружить неизвестные серверы e-mail (например, сервер файлов,
ненамеренно функционирующий как сервер e-mail), которые также
нужно будет отключить;
– изолирование сетей от Internet.
Сети могут переполниться трафиком «червей» в случае серьезного инфицирования «червями». Иногда «червь» генерирует такой
огромный трафик по всей Internet, что периметры сети становятся
полностью нарушенными. Лучше всего отсоединить организацию от
Internet, особенно, если наличие доступа к Internet является для организации, по существу, бесполезным по причине объемности трафика «червя». Такое действие должно защищать системы организации от атак внешних «червей»; если системы организации уже инфицированы, данное действие предотвратит их атаки в отношении
других систем и дополнительную перегрузку трафика.
Выявление зараженных узлов и уязвимых узлов значительно
усложняется динамической природой вычислительных средств. Если бы все узлы были включены (т.е. потребляли энергопитание) и
подключены к сети постоянно, то их чистка от вредоносного кода
была бы относительно легкой. Фактическая же ситуация состоит в
том, что узлы могут быть инфицированы и отключены, перенесены в
другие сети или оставлены без присмотра на время, пока владелец
системы будет отсутствовать в офисе. Уязвимые узлы, отключенные
на то время, пока их владельцы находятся в отпуске, могут быстро
инфицироваться, когда они будут включены снова. При выявлении
83
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
уязвимых узлов и зараженных узлов не следует полагаться исключительно на участие пользователя. Однако организациям часто не хватает персонала и времени, чтобы отслеживать каждую машину
вручную, особенно когда существует значительное число мобильных пользователей и пользователей на дому. Автоматизированные
методы также могут быть неадекватными для идентификации всех
узлов, например, тех, которые могут загружаться для многих операционных систем или которые могут использовать ПО виртуальных
операционных систем. Организации должны тщательно учитывать
такие проблемы до того, как произойдет значимый инцидент внедрения вредоносного кода с тем, чтобы эти организации были готовы реализовать эффективные стратегии сдерживания.
Некоторые организации конфигурируют свои сетевые периметры с тем, чтобы блокировать соединения со специфичными портами,
распространяющими «троянских коней», с целью предотвращения
взаимодействия компонента сервера и клиента с «троянским конем».
Однако такой подход обычно неэффективен. Известные «троянские
кони» используют сотни различных номеров портов, и многие «троянские кони» могут быть сконфигурированы так, чтобы использовать
любой номер порта. Более того, некоторые «троянские кони» используют те же самые номера портов, которые используются легитимными службами, поэтому их связи не могут быть блокированы номером
порта. Некоторые организации также реализуют блокирование порта
неправильно, так что иногда блокируются законные соединения. Реализация правил фильтрования в отношении каждого порта, используемого «троянским конем», будет также повышать требования,
предъявляемые к устройствам фильтрации. Отказ от всего трафика по
умолчанию и обеспечение разрешения только на авторизованные соединения являются в целом более эффективными, чем попытка блокировать специфические порты, используемые «троянским конем».
В основном порт, используемый «троянским конем», должен блокироваться только в том случае, если организация имеет серьезное инфицирование «троянскими конями».
4.3.3. Восстановление после инцидента внедрения
вредоносного кода
Антивирусное ПО эффективно идентифицирует и удаляет инфицирование вредоносным кодом. Однако некоторые инфицированные файлы нельзя «дезинфицировать». Файлы могут быть удалены
или заменены чистыми резервными копиями. Затронутое приложение может быть инсталлировано повторно. Если вредоносный код
84
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
обеспечил атакующим доступ на системном уровне, то может быть
невозможным определить, какие другие действия могли выполнить
атакующие. В таких случаях система должна быть либо восстановлена из предыдущей неинфицированной резервной копии, либо перестроена «с нуля». Затем эту систему следует защитить таким образом, чтобы она была невосприимчива к другой инфекции, присущей
тому же самому вредоносному коду. Рекомендуется также изменение всех паролей во всех системах, которые имели отношения с атакованной системой.
4.3.4. Сбор и обработка свидетельств инцидента
внедрения вредоносного кода
Часто вредоносный код передается либо автоматически, либо
случайно инфицированными пользователями, поэтому выявление
источника вредоносного кода является очень сложным и трудоемким процессом. Тем не менее сбор образцов вредоносного кода в некоторых случаях может быть полезным для проведения дальнейшего
расследования. Выявление источника вредоносного кода является
очень сложным и трудоемким процессом. Тем не менее сбор образцов вредоносного кода в некоторых случаях может быть полезным
для проведения дальнейшего расследования.
Контрольные вопросы
1. Определение инцидента внедрения вредоносного кода. Примеры атак, связанных с внедрением вредоносного кода.
2. Подготовка к обработке инцидента.
3. Защитные меры для предотвращения инцидентов внедрения
вредоносного кода.
4. Последовательность действий при обработке инцидентов внедрения вредоносного кода.
5. Порядок обработки инцидента внедрения вредоносного кода.
6. Обнаружение и анализ инцидента внедрения вредоносного кода.
7. Сдерживание и устранение инцидента внедрения вредоносного кода.
8. Восстановление после инцидента внедрения вредоносного кода.
9. Сбор и обработка свидетельств инцидента внедрения вредоносного кода.
85
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
5. Управление инцидентами сбора информации
5.1. Определение инцидента сбора информации.
Цели инцидента сбора информации
Инциденты сбора информации подразумевают действия, связанные с определением потенциальных целей и получением представления о сервисах, касающихся этих целей. Инциденты сбора
информации предполагают проведение «разведки» с целью:
– определения наличия цели, получения представления об окружающей ее сетевой топологии и о том, с кем обычно эта цель связана обменом информации;
– определения потенциальных уязвимостей цели или непосредственно окружающей ее сетевой среды, которые могут быть использованы.
Примерами атак сбора информации являются:
– сканирование DNS-сервера (системы доменных имен);
– отправка тестовых запросов по случайным сетевым адресам;
– зондирование системы;
– сканирование доступных сетевых портов в системе;
– сканирование одного или нескольких сервисов с известными
уязвимостями по диапазону сетевых адресов;
– пассивное прослушивание сети.
В некоторых случаях сбор информации расширяется и переходит в неавторизованный доступ, если, например, нарушитель при
поиске уязвимости системы пытается также получить к ней доступ.
Обычно это осуществляется автоматизированными инструментальными средствами взлома, которые не только производят поиск уязвимостей, но и автоматически пытаются использовать найденные
уязвимые системы, сервисы и (или) сети.
5.2. Планирование системы управления
инцидентами сбора информации
5.2.1. Подготовка к обработке инцидента
При подготовке к обработке инцидента необходимо построить
возможные сценарии известных инцидентов сбора информации.
В табл. 19 приведены критические события и связанные с ними
нежелательные события инцидента сбора информации.
86
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Таблица 19
Нежелательные события инцидента сбора информации
Критическое
Нежелательные события
событие
Идентификация доступных серверов и адресов в сети
с помощью:
– анализа заголовков передаваемых пакетов;
Идентификация
– сканирования DNS-сервера.
топологии сети
Идентификация активных узлов с помощью:
– отправки тестовых запросов по случайным сетевым адресам;
– зондирования сети
Идентификация операционной системы узла
с помощью зондирования сети.
Идентификация сетевых служб на узлах и версий
ПО этих служб путем:
– отправки тестовых запросов по случайным
сетевым адресам;
Идентификация
– анализа заголовков передаваемых пакетов,
уязвимостей системы
которые были перехвачены в процессе пассивного
прослушивания сети;
– зондирования сети.
Сканирование доступных сетевых портов.
Сканирование одного или нескольких сервисов
с известными уязвимостями по диапазону сетевых
адресов
Извлечение данных аутентификации
из
перехваченных в процессе пассивного
Идентификация
прослушивания сети пакетов.
способа получения
конфиденциальной
Извлечение содержания электронных писем,
информации
перехваченных в процессе пассивного
прослушивания сети
На рис. 18 представлены примеры сценариев развития инцидента
сбора информации.
Инцидент сбора информации может привести к раскрытию конфиденциальной информации при пассивном прослушивании сети
вследствие передачи ее в незащищенном виде по каналам связи или
вследствие получения атрибутов аутентификации. Это повлечет за собой материальный ущерб организации и ущерб ее репутации. Также,
если произошел инцидент сбора информации, следует считать, что
злоумышленник получил информацию об уязвимостях системы или
сети организации и планирует использовать эти данные при организа87
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ции атаки на систему. Вследствие этого организации будет нанесен
материальный ущерб, а если полученные злоумышленником данные
будут опубликованы, то будет нанесен ущерб репутации организации.
Сканирование
DNS-сервера
Рис. 18. Сценарии развития инцидента сбора информации
На рис. 19 представлены примеры сценариев последствий инцидента сбора информации.
Получение
информации для
планирования
нападения на
систему
Материальный
ущерб
Сбор
информации
Раскрытие
конфиденциальной
информации
Ущерб репутации
Рис. 19. Сценарии последствий инцидента сбора информации
88
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Сценарии инцидента сбора информации, сочетающие сценарии
развития и последствий инцидента сбора информации, представлены
на рис. 20.
Данная схема позволяет проанализировать сценарии инцидента
от вызвавших его нежелательных событий до негативных последствий, которые он за собой повлечет.
5.2.2. Выбор защитных мер
Защитные меры по противодействию инцидентам сбора информации, выбранные на основе результатов оценки рисков, нацелены
на противодействие реализации выявленных угроз и снижение возможности использования уязвимостей систем. Такими защитными
мерами, например, могут быть:
– установка и настройка МСЭ;
– использование технологии VPN (Virtual Private Network);
– установка СОВ и анализаторов пакетов для отслеживания специфического трафика;
– установка публично доступных услуг в безопасных сегментах
системы;
– выполнение регулярной оценки уязвимостей, чтобы идентифицировать риски и уменьшить их до приемлемого уровня;
– оперативная установка исправлений для программ и используемых операционных систем (patching).
Сами по себе инциденты сбора информации не наносят ущерба
производительности системы, обнаружить их трудно. Мерами по
обнаружению инцидентов сбора информации могут служить регулярные проверки статистики МСЭ, СОВ, мониторинг состояния интерфейсов систем.
Ввиду высокого уровня остаточного риска, появления новых инструментов и средств сбора информации выбранных защитных мер
может быть недостаточно. Необходима своевременная и оперативная
обработка инцидентов сбора информации, чтобы предупредить дальнейшие злоумышленные действия по отношению к системе.
На основе анализа сценариев инцидента должны быть определены защитные меры по сдерживанию, устранению инцидента и
восстановлению после него. Эти меры выбираются и реализуются
членами ГРИИБ в соответствии со сценарием развития инцидента.
89
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
90
Рис. 20. Сценарии инцидента сбора информации
90
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
К защитным мерам, сдерживающим инцидент сбора информации, относятся:
– анализ переданного злоумышленником трафика;
– выявление и изолирование затронутых узлов и систем;
– реализация фильтрации на основе анализа трафика.
Мерами по устранению инцидента сбора информации и восстановлению после него могут быть:
– выявление уязвимостей систем, узлов и сервисов;
– устранение выявленных уязвимостей;
– маскировка цели;
– изменение паролей во всех системах, данные аутентификации
которых могли быть перехвачены.
На рис. 21 представлен пример применения защитных мер в соответствии с последовательностью событий сценария инцидента
сбора информации, начинающегося с события «зондирование сети».
Рис. 21. Пример применения защитных мер на одном из сценариев
инцидента сбора информации
5.2.3. Формирование последовательности действий
при обработке инцидентов сбора информации
Для обеспечения эффективного реагирования на инцидент в организации должна быть сформирована последовательность действий
при обработке инцидентов сбора информации. Эта последовательность приводится в табл. 20. Последовательность действий может
меняться в зависимости от особенностей инцидентов и стратегий по
сдерживанию инцидента, выбранных конкретной организацией.
91
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Таблица 20
1
Последовательность действий
при обработке инцидента сбора информации
Действие
Анализ инцидента сбора информации
Сбор и документирование дополнительных свидетельств
(доказательств) инцидента для определения его
реальности и значимости
2
Определение значимости инцидента с точки зрения его
воздействия на бизнес
2.1
Идентификация затронутых активов и прогнозирование,
какие активы могут быть затронуты
2.2
2.3
3
Завершено
Оценивание существующих и потенциальных
воздействий инцидента
Определение по матрице значимости инцидентов
условий реагирования на основе технического
воздействия и затронутых активов
Сообщение об инциденте соответствующему
внутреннему персоналу и внешним организациям
Сдерживание, устранение инцидента и восстановление после инцидента
4
5
6
6.1
6.2
Выполнение начального сдерживания инцидента
(например, блокирование входящего подозрительного
трафика)
Получение, документирование, сохранение
и обеспечение безопасности свидетельств (доказательств)
инцидента
Необходимость удостовериться в сдерживании
инцидента
Анализ инцидента и определение, достаточно ли было
сдерживание (включая проверку других систем
на признаки вторжения)
Реализация дополнительных мер сдерживания
при необходимости
7
Устранение инцидента
7.1
Идентификация и минимизация всех уязвимостей,
которые были использованы
7.2
Удаление компонентов инцидента
8
9
Восстановление после инцидента
Подготовка завершающего отчета
Деятельность после инцидента
92
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
5.2.4. Формирование порядка обработки
инцидента сбора информации
В организации должен быть определен порядок обработки инцидентов сбора информации в зависимости от их значимости. Примерная матрица определения значимости инцидентов сбора информации показана в табл. 21.
Таблица 21
Примерная матрица приоритетов условий
при реагировании на инциденты сбора информации
Критичность (важность) активов, затрагиваемых
в настоящее время или которые, по всей
вероятности, будут затронуты инцидентом
Высокая
Существующее
(например,
воздействие или
связность
Средняя
вероятное будущее
с Internet,
(например,
Низкая
воздействие
Web-серверы,
серверы файлов,
(например,
инцидента
рабочие станции
серверы печати,
рабочие станции
системных
почтовый
пользователей)
сервер)
и ИБ администраторов, сервер
мониторинга)
Идентификация
способа получения
Значимость 1
Значимость 2
Значимость 3
конфиденциальной
информации
Идентификация
Значимость 1
Значимость 2
Значимость 3
уязвимостей
системы
Идентификация
Значимость 2
Значимость 3
Значимость 4
топологии сети
Заголовки столбцов показывают различную степень критичности активов, а заголовки строк  различные категории технического
воздействия. Уровень значимости инцидента сбора информации в
матрице определяет приоритетность его обработки.
5.3. Использование системы управления инцидентами
сбора информации
5.3.1. Обнаружение и анализ инцидента сбора информации
Обнаружение и анализ инцидентов сбора информации может
происходить с помощью различных предвестников и указателей ин93
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
цидента. В табл. 22 перечисляются возможные предвестники инцидента сбора информации и приводятся действия, которые могут предотвратить появление инцидента.
Таблица 22
Предвестники инцидента сбора информации
Предвестник
Действия по предотвращению
Данная информация может быть
получена, например, обманным путем,
Повышение интереса к структуре под видом социологического опроса
и деятельности организации, ее
по проблемам трудящихся или обеспечения
отдельных подразделений
технической безопасности и т.п.
или сотрудников. Полученная
Предотвратить утечку информации
о структуре и деятельности организации
информация нетехнического
характера может быть
можно с помощью ввода режима
использована для определения
секретности, оформления подписок
о неразглашении и т.д., информирования
направлений и инструментов
сотрудников о безопасности работы
атаки технического сбора
в Интернете, с электронной почтой
информации
и о возможных видах мошенничества
в сети
Члены ГРИИБ обязаны следить
за появлением новых инструментальных
технических средств, которые могут быть
использованы для сбора информации;
Недавно выпущенный инструмент изучение этих средств, а также
сбора информации
использование их для выявления
уязвимостей сетей и систем в своей
организации позволит идентифицировать
защитные меры для противодействия
новым угрозам
Помимо регулярной установки обновлений и исправлений для программ
и операционных систем от их
производителя, необходимо также
следить за информацией, появившейся,
Публикация информации
например, на информационных порталах
об уязвимостях операционных
систем и ПО
в Интернете, в специализированных
печатных изданиях или сообщениях
СМИ об угрозах и инцидентах
кибербезопасности и предпринимать
меры по противодействию им
Указатели инцидента – это признаки нежелательных событий
(см. табл. 19), которые могут быть выявлены с помощью:
94
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
– сообщений сетевых и узловых СОВ;
– просмотра статистики МСЭ;
– анализаторов реакции сетевых интерфейсов.
Указатели нежелательных событий инцидента сбора информации приведены в табл. 23.
Таблица 23
Указатели инцидента сбора информации
Возможные указатели
Нежелательные события
Сканирование DNS-сервера.
Отправка тестовых запросов
по случайным сетевым адресам.
Предупреждения СОВ
Зондирование сети.
об аномальном трафике в сети
Сканирование доступных сетевых портов.
Сканирование одного или нескольких сервисов с известными уязвимостями по диапазону сетевых адресов
Сканирование DNS-сервера.
Отправка тестовых запросов
по случайным сетевым адресам.
Сообщения об обнаружении
Зондирование сети.
вторжений в сеть или к узлу
Сканирование доступных сетевых портов.
Сканирование одного или нескольких
сервисов с известными уязвимостями
по диапазону сетевых адресов
Предупреждения ПО –
Пассивное прослушивание сети
анализаторов реакции сетевых
(перехват трафика)
интерфейсов (например, работа
узла в прослушивающем режиме)
Сканирование DNS-сервера.
Множество пакетов от одного
Отправка тестовых запросов
источника, адресованных
по случайным сетевым адресам.
различным машинам в сети
Зондирование сети.
Сканирование доступных сетевых портов
Сканирование DNS-сервера.
Множество пакетов,
Зондирование сети.
адресованных различным
Сканирование одного или нескольких
машинам в сети и направленных
сервисов с известными уязвимостями
на один и тот же порт
по диапазону сетевых адресов
Инциденты сбора информации сами по себе не наносят ущерба
деятельности организации. Но часто сбор информации расширяется
и переходит в другой инцидент, если, например, нарушитель при
выявлении уязвимости пытается ее использовать.
95
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Нежелательные события инцидента сбора информации могут
представлять собой последовательность разведывательных действий. Например, запросы DNS помогают выяснить, кто владеет тем
или иным доменом и какие адреса этому домену присвоены; отправка тестовых запросов по полученным адресам позволяет выявить активные узлы в сети; сканирование доступных сетевых портов позволяет идентифицировать используемые на узлах сетевые
службы и сервисы, версии программного обеспечения этих сервисов; анализ характеристик служб и сервисов позволяет злоумышленнику найти уязвимости системы и использовать их для проведения атаки. Важно как можно раньше предпринять меры по сдерживанию и устранению инцидента сбора информации, чтобы снизить
возможный ущерб.
5.3.2. Сдерживание инцидента сбора информации
Время реагирования на инцидент является критичным при
сдерживании инцидента сбора информации. Прежде всего следует
провести анализ переданного на незнакомый адрес трафика. Анализ
переданного трафика позволит установить, какую информацию мог
получить злоумышленник, от какого узла или системы, а также,
возможно, адрес получателя этой информации. Эти данные помогут
выявить затронутые системы и узлы, а также провести расследование инцидента сбора информации. Анализ переданного злоумышленником трафика позволит построить возможную картину будущей атаки на систему и препятствовать ей. По результатам анализа
трафика можно предпринять следующие меры по сдерживанию:
– изолирование затронутых узлов или служб на узле.
Если, например, при пассивном прослушивании сети злоумышленник перехватил пакеты, в которых передаются пароли, то
необходимо срочно выявить системы, узлы и услуги, которым они
принадлежат. Отсоединение узла от сети или отключение затронутой услуги, пока обработчики инцидента определяют, был ли скомпрометирован файл паролей, должно препятствовать атакующему
использовать эти пароли. В большинстве сред, однако, это не так.
Из-за доверенных отношений между системами и пользователями,
обеспечивающих одни и те же или пароли для многих систем, украденные пароли часто используются для доступа к другим системам. Инцидент может быстро расшириться от одного узла до многих узлов за минуты;
– реализация фильтрации на основе анализа трафика.
96
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Блокирование определенного вида пакетов должно способствовать прерыванию разведывательной деятельности злоумышленника.
Необходимо настроить МСЭ или маршрутизатор таким образом,
чтобы он не пропускал определенные пакеты. Хотя приемы фильтрации могут быть эффективны при сдерживании инцидентов, они
могут вносить дополнительные проблемы. Например, добавление
новых правил к маршрутизатору или межсетевому экрану может вызвать существенное снижение пропускной способности сети.
5.3.3. Устранение инцидента и восстановление
после инцидента сбора информации
В первую очередь члены ГРИИБ должны идентифицировать
уязвимости систем, узлов или служб на узлах, о которых мог получить информацию злоумышленник. Меры по устранению инцидента
сбора информации должны быть направлены на предотвращение
будущих атак на эти системы. Поэтому важно для обработчиков
идентифицировать все уязвимости и принять меры по их уменьшению или устранению.
Если анализ переданного злоумышленнику трафика показал,
что целью атаки был конкретный узел, то имеет смысл выполнить
«маскировку цели», т.е. присвоение этому узлу другого адреса IP.
Если целью являлась конкретная услуга узла, то услуга может быть
передана другому узлу – узлу без соответствующей уязвимости.
Рекомендуется изменение всех паролей во всех системах, данные аутентификации которых могли быть перехвачены.
5.3.4. Сбор и обработка свидетельств инцидента
сбора информации
При сборе и обработке свидетельств (доказательств) инцидента
сбора информации и подготовке отчета необходимо зафиксировать
относящиеся к этому инциденту данные, включающие предупреждения об обнаружении вторжения, журналы МСЭ, сообщения анализаторов состояния сетевых интерфейсов. Эти данные также могут являться основой для расследования инцидента сбора информации и последующей проверки эффективности процедур его обработки.
Контрольные вопросы
1. Определение инцидента сбора информации. Примеры инцидентов сбора информации.
2. Подготовка к обработке инцидента сбора информации.
97
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3. Защитные меры для предотвращения инцидентов сбора информации.
4. Последовательность действий при обработке инцидента сбора
информации.
5. Порядок обработки инцидента сбора информации.
6. Обнаружение и анализ инцидента сбора информации.
7. Сдерживание инцидента сбора информации.
8. Устранение инцидента и восстановление после инцидента
сбора информации.
9. Сбор и обработка свидетельств инцидента сбора информации.
98
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Заключение
Инциденты кибербезопасности: неавторизованный доступ, отказ
в обслуживании, внедрение вредоносного кода, сбор информации,
источниками которых являются внешние по отношению к защищаемым системам среды глобального информационного пространства, 
чрезвычайно опасны в силу своей высокой неопределенности. Обработка инцидентов кибербезопасности может быть успешной и прогнозируемой только при условии управления обработкой инцидентов
на всем их жизненном цикле и при условии последующего анализа с
целью определения возможности совершенствования обработки инцидентов кибербезопасности и реализации улучшения. Создание системы управления инцидентами кибербезопасности необходимо в любой организации, ИТКС которых являются частью глобального информационного пространства.
Разработка и реализация процедур и процессов управления инцидентами, формирование базы инцидентов, функции и роли группы
реагирования на инциденты – все это является сферой деятельности
специалистов по информационной безопасности.
Наряду с общим подходом к управлению инцидентами ИБ в
учебном пособии рассматриваются также наиболее важные процедуры управления конкретными инцидентами кибербезопасности с соответствующим информационным содержанием, что может использоваться будущими специалистами в практической деятельности по
обеспечению ИБ.
99
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Библиографический список
1. ISO/IEC 27035 Information technology  Security techniques 
Information security incident management.
2 . ISO/IEC TR 18044:2004(E) Information technology  Security
techniques  Information security incident management.
3. NIST 800-61 Computer Security Incident Handling Guide.
4 . ГОСТ Р ИСО/МЭК 17799:2005 Информационные технологии.
Практические правила управления информационной безопасностью.
5. ISO/IEC 31010:2009 Risk management  Risk assessment techniques.
6 . ГОСТ Р 541442010 Менеджмент рисков. Руководство по
применению организационных мер безопасности и оценки рисков.
Идентификация инцидентов.
100
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Приложение
(справочное)
СЦЕНАРИИ ИНЦИДЕНТА
1. Сценарии развития инцидента
Сценарии развития инцидента строятся с помощью дерева отказов. Построение дерева отказов [5] – это метод идентификации и
анализа факторов, которые могут способствовать определенному
критическому событию (называемому «конечным событием»). Причинные факторы идентифицируются дедуктивным методом, логическим образом систематизируются и представляются графическим
образом в виде древовидной схемы, изображающей нежелательные
события и их связи с конечным событием. Под нежелательным событием (НС) подразумевается причинный уровень в дереве отказов [6].
НС наиболее часто представляет события, которые касаются организации или поведения людей, которые могут всегда рассматриваться
как причина критического события. Взаимосвязи между событиями
выявляются в результате прослеживания событий в обратном порядке для того, чтобы отыскать возможные причины их возникновения.
Идентифицированные на древовидной схеме причинные события
могут быть событиями, связанными с отказами аппаратных компонентов, человеческими ошибками или любыми другими событиями,
ведущими к инциденту.
Дерево отказов строится в следующем порядке:
1) определяется критическое событие, которое должно анализироваться. Это может быть инцидент или, возможно, более широкий
результат этого инцидента;
2) начиная с критического события, идентифицируются возможные причинные нежелательные события, ведущие к нему;
3) каждое из этих событий анализируется с целью идентификации непосредственных причин его возникновения;
4) пошаговая идентификация нежелательных событий и их причин продолжается на более низких последовательных уровнях, пока
дальнейший анализ не перестанет быть информативным. События и
причинные факторы на самом низком анализируемом уровне называются основными событиями.
Структура дерева отказов приведена на рис. П.1.
101
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. П.1. Структура дерева отказов
Сценарии развития инцидента могут использоваться для идентификации угроз на этапе оценки рисков, а также для анализа произошедшего инцидента с целью выявить совокупность и последовательность событий, вызвавших инцидент.
2. Сценарии последствий инцидента
Сценарии последствий инцидента строятся на основе дерева событий. Дерево событий [5] – это графический метод представления
последовательностей событий, следующих за критическим событием; это индуктивный метод идентификации событий, следующих за
критическим, и их негативных последствий.
Дерево событий строится следующим образом:
1) определяется критическое событие;
2) идентифицируются вторичные критические события;
3) идентифицируются третичные события, которые следуют
за вторичными критическими событиями, или их негативные последствия;
4) критические события детализируются до уровня, определенного целями и границами анализа критического события. Таким
способом моделируются различные пути от исходного критического
события до его негативных последствий.
Структура дерева событий представлена на рис. П.2.
102
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. П.2. Структура дерева событий
Построение дерева событий может содействовать анализу сценариев последствий инцидента для того, чтобы идентифицировать варианты обработки, защитные меры или средства контроля и управления,
предназначенные для уменьшения нежелательных последствий.
3. Сценарии инцидента
Сценарии инцидента представляют собой совокупность сценариев его развития и последствий. Построить их можно с помощью
схемы «песочные часы» [6], представляющей собой комбинацию дерева отказов и дерева событий (рис. П.3).
Рис. П.3. Схема «песочные часы»
Такая схема позволяет проанализировать инцидент от вызвавших его нежелательных событий до негативных последствий, которые
он за собой повлечет.
103
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Учебное издание
Зефиров Сергей Львович,
Щербакова Анастасия Юрьевна
Управление инцидентами
кибербезопасности
Редактор В. В. Чувашова
Корректор Н. А. Сидельникова
Компьютерная верстка С. В. Денисовой
Подписано в печать 28.12.12.
Формат 60841/16 Усл. печ. л. 6,05.
Тираж 50. Заказ № 1077.
_______________________________________________________
Издательство ПГУ
440026, Пенза, Красная, 40
Тел./факс: (8412) 56-47-33; e-mail: iic@pnzgu.ru
104
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
105
Документ
Категория
ГОСТ Р
Просмотров
79
Размер файла
1 394 Кб
Теги
1997, кибербезопасности, инцидентами, управления
1/--страниц
Пожаловаться на содержимое документа