Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Управление инцидентами информационной безопасности на объектах информатизации с учетом нейтрализации воздействия человеческого фактора. Учебное пособи
.pdf
31
В1
В2
В3
В4
В5
В6
Базовый уровень
опасности инцидента
для объекта
Свыше 500 тыс. руб.
Низкий
Низкий
Средний
Средний
Высокий
Средний
От 10
до 100
Менее 50 тыс. руб.
Низкий
Очень низкий
Средний
Низкий
Высокий
Низкий
От 50 до 500 тыс. руб.
Низкий
Низкий
Средний
Низкий
Высокий
Средний
Свыше 500 тыс. руб.
Низкий
Низкий
Средний
Средний
Высокий
Средний
Более 100
Менее 50 тыс. руб.
Низкий
Низкий
Средний
Низкий
Высокий
Средний
От 50 до 500 тыс. руб.
Низкий
Низкий
Средний
Низкий
Высокий
Средний
Свыше 500 тыс. руб.
Низкий
Низкий
Средний
Средний
Высокий
Высокий
От 100 до
1 млн руб.
Менее 10
Менее 50 тыс. руб.
Низкий
Низкий
Средний
Средний
Высокий
Средний
32
В1
В2
В3
В4
В5
В6
Базовый уровень
опасности инцидента
для объекта
От 50 до 500 тыс. руб.
Низкий
Низкий
Средний
Средний
Высокий
Средний
Свыше 500 тыс. руб.
Низкий
Низкий
Средний
Средний
Высокий
Средний
От 10 до
100
Менее 50 тыс. руб.
Низкий
Низкий
Средний
Низкий
Высокий
Средний
От 50 до 500 тыс. руб.
Низкий
Низкий
Средний
Низкий
Высокий
Средний
Свыше 500 тыс. руб.
Низкий
Низкий
Средний
Средний
Высокий
Средний
Более 100
Менее 50 тыс. руб.
Низкий
Низкий
Средний
Низкий
Высокий
Средний
От 50 до 500 тыс. руб.
Низкий
Низкий
Средний
Низкий
Высокий
Средний
Свыше 500 тыс. руб.
Низкий
Низкий
Средний
Средний
Высокий
Средний
33
В1
В2
В3
В4
В5
В6
Базовый уровень
опасности инцидента
для объекта
Свыше
1 млн руб.
Менее 10
Менее 50 тыс. руб.
Низкий
Низкий
Средний
Средний
Высокий
Средний
От 50 до 500 тыс. руб.
Низкий
Низкий
Средний
Средний
Высокий
Высокий
Свыше 500 тыс. руб.
Низкий
Средний
Средний
Высокий
Высокий
Высокий
От 10 до
100
Менее 50 тыс. руб.
Низкий
Низкий
Средний
Средний
Высокий
Средний
От 50 до 500 тыс. руб.
Низкий
Низкий
Средний
Средний
Высокий
Высокий
Свыше 500 тыс. руб.
Низкий
Средний
Средний
Высокий
Высокий
Высокий
Более 100
Менее 50 тыс. руб.
Низкий
Средний
Средний
Средний
Высокий
Высокий
От 50 до 500 тыс. руб.
Низкий
Средний
Средний
Средний
Высокий
Высокий
Свыше 500 тыс. руб.
Низкий
Средний
Средний
Высокий
Высокий
Высокий
34
Заполнение данной анкеты и своевременное обновление исходных дан-
ных при необходимости позволит наиболее точно рассчитывать показатели
опасности инцидентов ИБ, реализация которых произошла или возможна в си-
стеме, с учетом индивидуальных параметров объекта.
2.2. ДЕТАЛИЗИРОВАННОЕ ОПИСАНИЕ ЭТАПА 2
МЕТОДИКИ УПРАВЛЕНИЯ ИНЦИДЕНТАМИ ИБ
Второй этап методики выполняется автоматически за счет применения
SIEM-систем. SIEM-система обеспечивает непрерывный мониторинг событий
ИБ и в случае фиксации симптома происхождения инцидента ИБ выдает сигнал
об обнаружении. Администратор ИБ получив сигнал от SIEM-системы находит
соответствующий симптом в базе данных.
SIEM-системы обычно используются для мониторинга, корреляции и
анализа активности в нескольких системах и приложениях, обнаружения внеш-
них и внутренних угроз, отслеживания действий пользователей или определен-
ных типов пользователей с доступом к критически важным данным, предостав-
ления аналитики в целях реагирования на инциденты, поиска угроз и автомати-
зации действий и рабочих процессов.
Ключом к обнаружению инцидентов в SIEM являются заранее прописан-
ные правила обнаружения, на основе которых системой и делается вывод об
аномальности тех или иных событий. Без четко прописанных правил система
является примитивным сборщиком логов.
В рамках платных решений ряд правил обнаружения уже прописан в си-
стеме, однако все равно при внедрении этого будет недостаточно и специали-
стам придется прописывать ряд правил, а также дописывать спецификацию уже
имеющихся.
Работа с SIEM-системой на объекте — это комплексная и непрерывная
задача, поскольку условия функционирования и особенности предприятия ди-
намичны, а значит, и работа с правилами должна осуществляться специалиста-
ми непрерывно.
Общая модель процесса разработки и внедрения новых правил обнаруже-
ния для SIEM-систем представлена на рис. 3.
35
Рис. 3. Общая модель процесса разработки
и внедрения новых правил обнаружения для SIEM-систем
В рамках первого шага необходимо выделить источники данных (собы-
тия), на основе которых будет срабатывать правило корреляции, для этого необ-
ходимо ответить на несколько вопросов и предпринять соответствующие дей-
ствия.
A. Есть ли нормализованные события?
Для событий, собранных с разных источников, могут отличаться формат
(TXT, XML, JSON) и стандарт записи. Для того чтобы была возможность анализа потока событий требуется преобразовать все события к единому виду. Нор-
мализованное событие представляет собой совокупность полей, заполненных
данными из необработанного события согласно правилу нормализации.
Если необходимые события в нормализованном виде отсутствуют, необ-
ходимо зарегистрировать задачу на подключение в веб-системе управления задачами (наиболее популярные виды данных систем — Jira и Redmine) со следующими данными: вендор, устройство, приложение, событие.
36
Пример: вендор — Microsoft, устройство — Windows
приложение — Security, событие — Event ID 4624.
B. Необходимо ли обогащение?
Обогащение событий представляет собой заполнение полей событий со-
гласно правилам обогащения. Поля заполняются данными, указанными в правиле обогащения или полученными из табличных списков.
Процесс обогащения необходим для дополнения «сырых» событий информацией, с помощью которой можно будет реализовать гипотезу сценария
обнаружения.
Пример: Обогащение геолокации адреса. Для того чтобы произвести обогащение геолокации адреса в первую очередь необходимо получить новые
GeoIP-списки, это списки, содержащие данные об IP-адресах пользователей и
их геолокации (страна, город). Получить эти данные можно из различных баз
данных, самой оптимальной базой данных для получения корректных обнов-
ленных списков является Maxmind. После получения списков, необходимо перенести данные табличный список в SIEM, затем правилом обогащения от-
фильтровать события, которые имеют поля src.ip или dst.ip и из табличного
списка добавить нужную информацию в dst.geo.country.
C. Необходимо ли агрегирование?
Поток событий может содержать однотипные события, отличающиеся
значением одного или нескольких полей (например, временем регистрации).
Для сокращения количества таких событий выполняется агрегация событий.
Агрегация событий — это процесс отбора (в потоке нормализованных и
корреляционных событий) событий, которые удовлетворяют условию заранее
настроенного правила агрегации, и объединения их в одно агрегированное со-
бытие.
Как правило, агрегация осуществляется автоматически при помощи имеющихся в системе утилит, например, в MP SIEM это утилита aggregator-cli.
На втором шаге производится эмуляция атаки. Цель — воспроизвести
(смоделировать) действия злоумышленника для генерация «сырых» событий,
которые в дальнейшем будут использованы для корреляции при срабатывании
правила и в которых будут выделены вредоносные сигнатуры.
На третьем шаге осуществляется непосредственно разработка правила.
После эмуляции (тестирования) атаки выделяются необходимые события, в ко-
торых будет осуществляться поиск вредоносных сигнатур для фильтрации.
После чего необходимо установить паттерны (шаблоны) вредоносной активности. В рамках обхода систем обнаружения злоумышленники могут ис-
37
пользовать различные техники, например, обфускация (изменение вида) кода.
Для того чтобы усложнить процесс обхода обнаруживающих систем нам необ-
ходимо определить в событиях паттерны, которые обязательно должны присут-
ствовать при атаке.
Шаг четыре — тестирование правила, на данном этапе необходимо убедиться в том, что написанное правило срабатывает при исполнение вредоносной активности.
Шаг пять — установка правила тестовую среду, которая максимально
приближена к реальному функционалу системы, необходима для первичного
осмотра правила при работе в SIEM.
На данном шаге:
- исключаются возможные ложные события легитимной активности поль-
зователей или ПО, при необходимости производится обогащение правил дан-
ными для исключения ложной корреляции;
- проверяется служба correlation, отвечающая за корреляцию, в промежуточном ПО, которое хранит очередь передаваемых данных — RABBITMQ. При
увеличении очереди службы производится пересмотр правила, чтобы обнаружить код, который нагружает систему;
- сформированные правила добавляются в SIEM, после чего выгружается
контент из базы знаний и обновляется репозиторий.
Финальный шаг — установка правила в продуктовую среду. Включает в
себя установку правил в SIEM и обновление репозитория (может не понадобиться, если на пятом шаге не было выявлено проблем), а также подготовку по-
дробного описания сценария обнаружения (необходимо для общей базы «ООО
ИБ» ATT&CK, где аналитики смогут быстро разобраться в его функционирова-
нии, при подготовке описания необходимо привести примеры корреляции собы-
тия, которые удалось получить при тестирование на шаге 4).
Когда работа с правилами производится системно и непрерывно, система
обладает высокой эффективностью и при обнаружении аномальных событий
выдает оповещение. Но также стоит учитывать общую зрелость системы ин-
формационной безопасности компании, поскольку чем больше на объекте име-
ется средств защиты, с которых можно получить логи (сетевые события), тем
точнее и комплекснее будет работа с SIEM. В табл. 8 представлен общий перечень событий ИБ, которые может отследить SIEM-система в сопоставлении с
теми средствами защиты, которые являются ключевыми источниками этих событий и обнаружения аномалий.
38
Таблица 8
События ИБ, отслеживаемые SIEM-системой
События ИБ (симптомы)
Источники событий
Вредоносный контент, доставленный легальным образом, как
правило, по электронной почте
(спам и фишинговые атаки)
- прокси-серверы с контролем контента
- средства защиты веб-трафика
- средства защиты почты
- средства защиты конечных узлов со встроенными моду-
лями контроля веб-ресурсов и электронной почты
Сбор данных об инфраструктуре
компании, определение доступ-
ных сервисов, поиск уязвимых
узлов
- межсетевые экраны
- средства обнаружения и предотвращения вторжений
Нарушение доступно-
сти отдельных сервисов и си-
стем в целом (например, в слу-
чае DDoS-атаки)
- межсетевые экраны
- системы обнаружения и предотвращения вторжений
- системы выявления и блокировки сетевых DoS-атак
Эксплуатация уязвимостей в
компонентах системы
- средства обнаружения и предотвращения вторжений
Использование хакерских ути-
лит, применяемых для взлома
систем или иных противоправных действий
- средства обнаружения и предотвращения вторжений
- сканеры уязвимостей и средства аудита
- антивирусные средства защиты
Выполнение вредоносного кода
- антивирусные средства защиты
- средства обнаружения и предотвращения вторжений
Нарушение политик ИБ, невыполнение требований нормативных документов (ПП 1119, при-
каза ФСТЭК № 21), корпоративных политик безопасности
- сканеры уязвимостей
Утечка конфиденциальных дан-
ных по любым коммуникационным каналам
- системы предотвращения утечек данных
Выявление аномалий, существенных отклонений парамет-
ров объекта защиты или его по-
ведения от ранее установленной
нормы
- межсетевые экраны нового поколения (NGFW)
- системы предотвращения течек данных
- системы класса User and Entity Behavior Analytics
Таким образом, использование SIEM-систем при условиях достаточной
зрелости системы информационной безопасности объекта в целом, позволяет
обеспечить непрерывный мониторинг работы систем объекта, который и является основой управления инцидентами ИБ. Однако задача управления не только
обнаружить инцидент, но и нейтрализовать его или же минимизировать воз-
можные последствия. Решение этой задачи требует разработки дополнительного подхода, который с учетом получаемых от SIEM данных позволит провести
дальнейшую работу по снижению риска.
39
2.3. ДЕТАЛИЗИРОВАННОЕ ОПИСАНИЕ ЭТАПА 3
МЕТОДИКИ УПРАВЛЕНИЯ ИНЦИДЕНТАМИ ИБ
На 3-м этапе методики, используя информацию, представленную в базе
данных, а также полученную на этапе 1 оценки базового уровня опасности ин-
цидента ИБ для объекта, Администратор ИБ может оперативно оценить опас-
ность конкретного инцидента (на основе расчетов по формуле 1, представлен-
ной ниже в этом пункте) и ознакомиться с контрмерами, которые необходимо
применить для нейтрализации инцидента.
От того, насколько оперативно будут реализованы нейтрализующие меро-
приятия, зависит напрямую масштаб возможных последствий. При быстрой ре-
акции сокращается время простоя системы (что напрямую связано с финансо-
выми убытками), время на восстановление системы, а также в ряде случаев вовремя примененные меры могут и вовсе предотвратить инцидент.
База данных (БД) содержит в себе сведения об инциденте, эффективные
контрмеры, а также признаки аномалий, которые может обнаружить SIEM-
система. Именно эта особенность позволит обеспечить системное и эффективное управление инцидентами ИБ, поскольку показатели непрерывного монито-
ринга будут связаны с рекомендациями по минимизации последствий обнаруженной активности.
Для описания БД возможных инцидентов за основу будут взяты 6 классов
признаков — симптомы, угрозы, последствия, потери, контрмеры, и опасность.
Каждый инцидент в базе характеризуется обладанием определенных признаков
из каждой категории. В случае возникновения инцидента происходит считыва-
ние из базы данных множества признаков, которыми он обладает.
Класс симптомы. Включает в себя признаки аномальной активности, ко-
торые может обнаружить SIEM-система при реализации того или иного инци-
дента. В первую очередь необходим для построения взаимодействия базы дан-
ных с имеющейся на объекте SIEM-системой. Однако если она отсутствует на
объекте, этот класс также может быть полезен при ручном мониторинге сетевых
событий и в качестве классификатора инцидентов.
Класс угрозы. Необходим для комплексного описания контрмер для инци-
дентов различной симптоматики. За основу будут взяты угрозы, представлен-
ные в банке данных угроз ФСТЭК. Именно использование в рамках данной БД
угроз дает преимущества и еще одну функциональную возможность. У каждого
предприятия должен быть утвержден документ Модели угроз, в котором происходит оценка того, насколько та или иная угроза актуальна для объекта. Имея
данные о предположительно актуальных угрозах, оператор сможет при помощи
информации из базы данных посмотреть какие инциденты наиболее вероятны к
реализации на объекте и принять превентивные меры для того, чтобы снизить
эту вероятность.
40
Класс последствия. Последствия включают в себя возможный реальный
ущерб. Выделяемые в рамках БД последствия: простой системы, выход обору-
дования из строя, нарушение доступа к данным, разглашение данных.
Класс потери. Потери — это финансовый эквивалент ущерба возможный
в случае наступления вышеописанных последствий. Выделяемые в рамках БД
потери: репутационные потери, порождающие финансовые убытки, затраты на
иски и компенсации, затраты на восстановление оборудования, затраты на
штрафы в соответствии с законодательством.
Класс контрмеры. Включает в себя перечень мер, которые должны быть
применены на объекте для нейтрализации или минимизации последствий инцидента ИБ. Подразделяются на меры, которые можно применить превентивно и
меры, которые необходимо применить, в случае если симптом уже обнаружен.
Превентивные меры также целесообразно применить поле того, как инцидент
будет полностью нейтрализован.
Класс опасность. Включает числовой показатель общей опасности инци-
дента.
Прежде чем сформировать основную базу данных, необходимо описать
порядок расчета показателя опасности.
Показатель опасности инцидента рассчитывается по формуле 1:
U = O × P,
(1)
где О — базовый уровень опасности инцидента ИБ для объекта, вычисляется на
основании анкеты внесения первичной информации (Этап 1, табл. 6, 7), если
уровень опасности согласно анкете очень низкий, показателю О присваивается
значение 0,2, низкий — 0,4, средний — 0,6, высокий — 0,8, очень высокий — 1;
Р — коэффициент опасности инцидента, содержащийся в БД, выставляется на
основе потенциальных последствий и потерь, которые может повлечь инцидент
без привязки к конкретному объекту (высокая опасность — 1, средняя — 0,7,
низкая — 0,4).
Итоговый показатель опасности инцидента для объекта интерпре-
тируется на основе шкалы Харрингтона:
• очень высокая опасность инцидента (U = 0,81 и более);
• высокая опасность инцидента (U = 0,64 – 0,8);
• средняя опасность инцидента (U = 0,38 – 0,63);
• низкая опасность инцидента (U = 0,21 – 0,37);
• очень низкая опасность инцидента (U = 0 – 0,2).
В табл. 9 представлена комплексная база данных, включающая детальное
описание всех необходимых классов для инцидента ИБ.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]