Что такое инцидент информационной безопасности
инцидент информационной безопасности
2.10 инцидент информационной безопасности (information security incident): Любое непредвиденное или нежелательное событие, которое может нарушить деятельность или информационную безопасность.
— утрата услуг, оборудования или устройств;
— системные сбои или перегрузки;
— несоблюдение политик или рекомендаций;
— нарушение физических мер защиты;
— неконтролируемые изменения систем;
— сбои программного обеспечения и отказы технических средств;
— нарушение правил доступа.
3.15 инцидент информационной безопасности (information security incident): Единичное событие или серия нежелательных или неожиданных событий, связанных с информационной безопасностью, которые со значительной вероятностью способны нанести ущерб бизнес-операциям (деловым операциям) и поставить под угрозу информационную безопасность.
3.3 инцидент информационной безопасности (information security incident): Появление одного или нескольких нежелательных или неожиданных событий ИБ, с которыми связана значительная вероятность компрометации бизнес-операций и создания угрозы ИБ.
инцидент информационной безопасности: Любое непредвиденное или нежелательное событие, которое может нарушить деятельность или информационную безопасность.
— утрата услуг, оборудования или устройств;
— системные сбои или перегрузки;
— несоблюдение политики или рекомендаций по ИБ;
— нарушение физических мер защиты;
— неконтролируемые изменения систем;
— сбои программного обеспечения и отказы технических средств;
— нарушение правил доступа.
3.3.22 инцидент информационной безопасности (information security incident): Одно или серия нежелательных или неожиданных событий информационной безопасности, которые имеют значительную вероятность компрометации бизнес-операции и угрожают информационной безопасности.
Смотри также родственные термины:
3.11. инцидент информационной безопасности организации банковской системы Российской Федерации: событие, вызывающее действительное, предпринимаемое или вероятное нарушение информационной безопасности организации банковской системы Российской Федерации.
Нарушение может вызываться либо ошибкой людей, либо неправильным функционированием технических средств, либо природными факторами (например, пожар или наводнение), либо преднамеренными злоумышленными действиями, приводящими к нарушению конфиденциальности, целостности, доступности, учетности или неотказуемости.
Полезное
Смотреть что такое «инцидент информационной безопасности» в других словарях:
ИНЦИДЕНТ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ — Любое непредвиденное или нежелательное событие, которое может нарушить деятельность или информационную безопасность Примечание. Инцидентами информационной безопасности являются: а) утрата услуг, оборудования или устройств; б) системные сбои или… … Комплексное обеспечение безопасности и антитеррористической защищенности зданий и сооружений
Инцидент информационной безопасности организации банковской системы РФ — 3.46. Инцидент информационной безопасности; инцидент ИБ: Событие, указывающее на свершившуюся, предпринимаемую или вероятную реализацию угрозы ИБ. Примечания. 1. Реализация угрозы ИБ реализация нарушения свойств ИБ информационных активов… … Официальная терминология
инцидент информационной безопасности организации банковской системы Российской Федерации — 3.11. инцидент информационной безопасности организации банковской системы Российской Федерации: событие, вызывающее действительное, предпринимаемое или вероятное нарушение информационной безопасности организации банковской системы Российской… … Словарь-справочник терминов нормативно-технической документации
осознание информационной безопасности — 3.9. осознание информационной безопасности : понимание организацией необходимости самостоятельно на основе принятых в ней ценностей и накопленных знаний формировать и учитывать в рамках основной деятельности (бизнеса) прогноз результатов от… … Словарь-справочник терминов нормативно-технической документации
СТО БР ИББС 1.0-2006: Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Общие положения — Терминология СТО БР ИББС 1.0 2006: Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Общие положения: 3.3. автоматизированная банковская система : автоматизированная система, реализующая банковский… … Словарь-справочник терминов нормативно-технической документации
ГОСТ Р 53114-2008: Защита информации. Обеспечение информационной безопасности в организации. Основные термины и определения — Терминология ГОСТ Р 53114 2008: Защита информации. Обеспечение информационной безопасности в организации. Основные термины и определения оригинал документа: 3.1.19 автоматизированная система в защищенном исполнении ; АС в защищенном исполнении:… … Словарь-справочник терминов нормативно-технической документации
ГОСТ Р ИСО/МЭК ТО 18044-2007: Информационная технология. Методы и средства обеспечения безопасности. Менеджмент инцидентов информационной безопасности — Терминология ГОСТ Р ИСО/МЭК ТО 18044 2007: Информационная технология. Методы и средства обеспечения безопасности. Менеджмент инцидентов информационной безопасности: 3.4 группа реагирования на инциденты информационной безопасности (ГРИИБ)… … Словарь-справочник терминов нормативно-технической документации
ГОСТ Р ИСО/ТО 13569-2007: Финансовые услуги. Рекомендации по информационной безопасности — Терминология ГОСТ Р ИСО/ТО 13569 2007: Финансовые услуги. Рекомендации по информационной безопасности: 3.4 активы (asset): Все, что имеет ценность для организации [2]. Определения термина из разных документов: активы 3.58 анализ риска (risk… … Словарь-справочник терминов нормативно-технической документации
ГОСТ Р ИСО ТО 13569-2007: Финансовые услуги. Рекомендации по информационной безопасности — Терминология ГОСТ Р ИСО ТО 13569 2007: Финансовые услуги. Рекомендации по информационной безопасности: 3.4 активы (asset): Все, что имеет ценность для организации [2]. Определения термина из разных документов: активы 3.58 анализ риска (risk… … Словарь-справочник терминов нормативно-технической документации
Работа с инцидентами информационной безопасности
Доброго дня, уважаемый хабрахабр!
Я продолжаю публикацию статей из практики по информационной безопасности.
В этот раз речь пойдёт о такой важной составляющей, как инциденты безопасности. Работа с инцидентами займёт львиную долю времени после установления режима информационной безопасности (приняты документы, установлена и настроена техническая часть, проведены первые тренинги).
Информирование об инцидентах
Перво наперво необходимо получить информацию об инциденте. Этот момент необходимо продумать ещё на этапе формирования политики безопасности и создания презентаций по ликбезу в ИБ для сотрудников.
Основные источники информации:
1. Helpdesk.
Как правило (и это хорошая традиция) о любых неполадках, неисправностях или сбоях в работе оборудования звонят или пишут в хелпдеск вашей IT-службы. Поэтому необходимо заранее «встроиться» в бизнес-процесс хелпдеска и указать те виды инцидентов, с которыми заявку будут переводить в отдел информационной безопасности.
2. Сообщения непосредственно от пользователей.
Организуйте единую точку контакта, о чём сообщите в тренинге по ИБ для сотрудников. На данный момент отделы ИБ в организациях, как правило, не очень большие, зачастую из 1-2 человек. Поэтому будет несложно назначить ответственного за приём инцидентов, можно даже не заморачиваться с выделением адреса электропочты под нужды IS Helpdesk.
3. Инциденты, обнаруженные сотрудниками ИБ.
Тут всё просто, и никаких телодвижений для организации такого канала приёма не требуется.
4. Журналы и оповещения систем.
Настройте оповещения в консоли антивируса, IDS, DLP и других систем безопасности. Удобнее использовать аггрегаторы, собирающие данные также из логов программ и систем, установленных в вашей организации. Особое внимание нужно уделить точкам соприкосновения с внешней сетью и местам хранения чувствительной информации.
Категорирование инцидента
Хоть инциденты безопасности разнообразны и многообразны, их довольно легко разделить на несколько категорий, по которым проще вести статистику.
1. Разглашение конфиденциальной или внутренней информации, либо угроза такого разглашения.
Для этого необходимо иметь, как минимум, актуальный перечень конфиденциальной информации, рабочую систему грифования электронных и бумажных носителей. Хороший пример — шаблоны документов, практически на все случаи жизни, находящиеся на внутреннем портале организации или во внутренней файлопомойке, по умолчанию имеют проставленный гриф «Только для внутреннего использования».
Немного уточню про угрозу разглашения, в предыдущем посте я описывал ситуацию, когда документ с грифом «Только для внутреннего использования» был вывешен в общем холле, смежным с другой организацией. Возможно, самого разглашения и не было (вывешено было после окончания рабочего дня, да и замечено было очень быстро), но факт угрозы разглашения — на лицо!
2. Несанкционированный доступ.
Для этого необходимо иметь список защищаемых ресурсов. То есть тех, где находится какая-либо чувствительная информация организации, её клиентов или подрядчиков. Причём желательно внести в эту категорию не только проникновения в компьютерную сеть, но и несанкционированный доступ в помещения.
3. Превышение полномочий.
В принципе можно объединить этот пункт с предыдущим, но лучше всё-таки выделить, объясню почему. Несанкционированный доступ подразумевает доступ тех лиц, которые не имеют никакого легального доступа к ресурсам или помещениям организации. Это внешний нарушитель, не имеющий легального входа в вашу систему. Под превышением полномочий же понимается несанкционированный доступ к каким-либо ресурсам и помещениям именно легальных сотрудников организации.
4. Вирусная атака.
В этом случае необходимо понимать следующее: единично заражение компьютера сотрудника не должно повлечь за собой разбирательство, так как это можно списать на погрешность или пресловутый человеческий фактор. Если же заражен ощутимый процент компьютеров организации (тут уже исходите из общего количества машин, их распределенности, сегментированности и тд), то необходимо разворачивать полновесную отработку инцидента безопасности с необходимыми поисками источников заражения, причин и т.д.
5. Компрометация учетных записей.
Этот пункт перекликается с 3. Фактически инцидент переходит из 3 в 5 категорию, если в ходе расследования инцидента выясняется, что пользователь в этот момент физически и фактически не мог использовать свои учётные данные.
Классификация инцидента
С этим пунктом в работе с инцидентами можно поступить 2-мя путями: простым и сложным.
Простой путь: взять соглашение об уровне сервиса вашей IT-службы и подогнать под свои нужды.
Сложный путь: на основе анализа рисков выделить группы инцидентов и/или активов, в отношении которых решение или устранение причин инцидента должны быть незамедлительными.
Простой путь неплохо работает в небольших организациях, где не так уж и много закрытой информации и нет огромного количества сотрудников. Но стоит понимать, что IT-служба исходит в SLA из своих собственных рисков и статистики инцидентов. Вполне возможно, что зажевавший бумагу принтер на столе генерального директора будет иметь очень высокий приоритет, в том случае, как для вас важнее будет компрометация пароля администратора корпоративной БД.
Сбор свидетельств инцидента
Есть особенная прикладная наука — форензика, которая занимается вопросам криминалистики в области компьютерных преступлений. И есть замечательная книга Федотова Н.Н. «Форензика — компьютерная криминалистика». Я не буду сейчас расписывать детально аспекты форензики, просто выделю 2 основных момента в сохранении и предоставлении свидетельств, которых необходимо придерживаться.
• Для бумажных документов: подлинник хранится надежно с записью лица, обнаружившего документ, где документ был обнаружен, когда документ был обнаружен и кто засвидетельствовал обнаружение. Любое расследование должно гарантировать, что подлинники не были сфальсифицированы
• Для информации на компьютерном носителе: зеркальные отображение или любого сменного носителя, информации на жестких дисках или в памяти должны быть взяты для обеспечения доступности. Должен сохраняться протокол всех действий в ходе процесса копирования, и процесс должен быть засвидетельствован. Оригинальный носитель и протокол (если это невозможно, то, по крайней мере, одно зеркальное отображение или копия), должны храниться защищенными и нетронутыми
После устранения инцидента
Итак, инцидент исчерпан, последствия устранены, проведено служебное расследование.
Но работа на этом не должна завершаться.
Дальнейшие действия после инцидента:
• переоценка рисков, повлекших возникновение инцидента
• подготовка перечня защитных мер для минимизации выявленных рисков, в случае повторения инцидента
• актуализация необходимых политик, регламентов, правил ИБ
• провести обучение персонала организации, включая сотрудников IT, для повышения осведомленности в части ИБ
То есть необходимо предпринять все возможные действия по минимизации или нейтрализации уязвимости, повлекшей реализацию угрозы безопасности и, как результат, возникновение инцидента.
Несколько советов
1. Ведите журнал регистрации инцидентов, где записывайте время обнаружения, данные сотрудника, обнаружившего инцидент, категорию инцидента, затронутые активы, планируемое и фактическое время решения инцидента, а так же работы, проведенные для устранения инцидента и его последствий.
2. Записывайте свои действия. Это необходимо в первую очередь для себя, для оптимизации процесса решения инцидента.
3. Оповестите сотрудников о наличие инцидента, что бы во-первых они не мешали вам в расследовании, во-вторых исключили пользование затронутыми активами на время расследования.
Инциденты информационной безопасности – выявление и расследование
Хотя бы один раз за весь период работы большинство компаний сталкивалось с инцидентами информационной безопасности. Речь идет об одном, двух и более неожиданных и нежелательных событиях в корпоративной сети, которые приводят к серьезным финансовым и репутационным последствиям. Например, доступ третьих лиц к закрытой информации организации. К классическим примерам можно отнести значительное искажение инфоактивов, а также хищение персональных данных пользователей (клиентской базы, проектная документация).
Не только крупные корпорации, но и небольшие фирмы различных организационно-правовых форм и размеров время от времени сталкиваются с кибератаками. Количество пострадавших компаний ежегодно увеличивается. Действия злоумышленников приводят к большим убыткам пострадавших организаций.
Есть несколько основных рисков внутри корпораций и фирм:
Основная проблема многих организаций в том, что в активно развивающемся мире киберугроз, большинство организаций даже не задумывается об информационной безопасности до возникновения инцидента. Поэтому часто нет резервных копий, доступ к данным есть у всех сотрудников, даже если они не пользуются ими в своей работе, а сеть ничем не защищена, и внедрить туда вредоносное ПО или заблокировать работу сервера организации может фактически любой желающий.
Классификация инцидентов
Аномалии, с которыми сталкиваются предприятия можно классифицировать по следующим признакам:
Существует категорирование инцидентов, позволяющее прописать их в политике безопасности и предотвращать их уже по первым признакам:
1. Несанкционированный доступ. Сюда стоит отнести попытки злоумышленников беспрепятственно войти в систему. Яркими примерами нарушения можно назвать поиск и извлечение различных внутренних документов, файлов, в которых содержатся пароли, а также атаки переполнения буфера, направленные на получение нелегитимного доступа к сети.
2. Угроза или разглашение конфиденциальной информации. Для этого нужно получить доступ к актуальному списку конфиденциальных данных.
3. Превышение полномочий определенными лицами. Речь идет о несанкционированном доступе работников к определенным ресурсам или офисным помещениям.
Что делать при обнаружении инцидента?
Управление аномальными событиями в сети подразумевает не только оперативное обнаружение и информирование службы информационной безопасности, но и их учет в журнале событий. В журнале автоматически указывается точное время обнаружения утечки информации, личные данные сотрудника, который обнаружил атаку, категорию события, все затронутые активы, планируемое время устранения проблемы, а также действия и работы, направленные на устранение события и его последствий.
Современным компаниям ручной способ мониторинга инцидентов уже не подходит. Так как аномалии происходят за секунды и требуется мгновенное реагирование. Для этого необходимы автоматизированные решения по информационной безопасности, которые непрерывно мониторят все, что происходит в сети организации оперативно реагируют на инциденты, позволяя принимать меры в виде блокировки доступа к данным, выявления источника события и быстрого расследования, в идеале до совершения инцидента.
После расследования, выполняя правила корреляции, которые свидетельствуют о вероятных попытках причинения вреда безопасности данных подобными способами, создается карточка данного инцидента и формируется политика безопасности. В дальнейшем подобные атаки будут подавлены и приняты меры до совершения активных действий со стороны сотрудников и внешних источников угроз.
Реагирование на утечку данных
При обнаружении нарушений в сети организации рекомендован следующий алгоритм действий со стороны службы информационной безопасности:
1. Фиксация состояния и анализ информационных ресурсов, которые были задействованы.
2. Координация работы по прекращению влияния информационных атак, проведение которых спровоцировало появление инцидента.
3. Анализ всего сетевого трафика.
4. Локализация события.
5. Сбор важных данных для установления причин происшествия.
6. Составление перечня мер, направленных на ликвидацию последствий инцидента, который нанес урон.
7. Устранение последствий.
8. Контроль устранения последствий.
9. Создание политик безопасности и подробного перечня рекомендаций, направленных на совершенствование всей нормативной документации.
Выявление причин инцидента безопасности
Анализ ситуации позволяет оценить риски и возможные последствия инцидента.
После того, как последствия события полностью устранены, обязательно проводится служебное расследование. Оно требует привлечения целой команды опытных специалистов, которые самостоятельно определяют порядок изучения фактов и особенностей произошедшего. Дополнительно используются всевозможные публичные отчеты, аналитические средства, потоки сведений обо всех угрозах, а также другие источники, которые могут пригодиться в процессе изучения конкретного кейса. Квалифицированные специалисты устраняют вредоносное программное обеспечение, закрывают возможные уязвимости и блокируют все попытки нелегитимного доступа.
По факту расследования составляют перечень мер, направленных на профилактику аналогичных кибератак. Дополнительно составляется список действий моментального реагирования в случае, если имело место проникновение вредоносного ПО в систему. Нужно провести обучение персонала фирмы для повышения киберграмотности.
Решения для информационной безопасности организации
Для предотвращения инцидентов ИБ необходимо внедрить специализированные решения, способные в реальном времени выявлять и реагировать на них даже по первым признакам до непосредственного хищения или других мошеннических действий.
Внедрение решений по информационной безопасности позволяет избежать многочисленных финансовых и репутационных рисков.
Управление инцидентами ИБ (конспект лекции)
Цикл лекций по дисциплине «Автоматизация процессов управления информационной безопасностью»
CC BY 4.0 © Рахметов Р. для ООО «Интеллектуальная безопасность» (Security Vision), 2020
Угроза ИБ возникает при наличии следующих взаимосвязанных компонентов:
источник угрозы + уязвимость актива + способ реализации угрозы + объект воздействия + вредоносное воздействие и его последствия.
Угроза ИБ – это потенциальная причина возникновения событий ИБ и инцидентов ИБ.
Событие ИБ – это изменение состояния элементов ИТ-инфраструктуры, которое может свидетельствовать о возникновении инцидента ИБ.
Инцидент ИБ – это событие ИБ, приводящее к несанкционированному изменению состояния защищенности информации (конфиденциальности, целостности, доступности), т.е. к реализации угрозы ИБ.
Определения по стандарту ISO 27000:2016:
Событие ИБ – это определенное состояние системы, сервиса или сети, указывающее на вероятное нарушение политики ИБ или сбой мер защиты или на некую ранее неизвестную ситуацию, которая может иметь отношение к ИБ.
Инцидент ИБ – это одно или несколько нежелательных или неожиданных событий ИБ, которые со значительной вероятностью указывают на компрометацию бизнес-процессов или реализованную угрозу ИБ.
Сбор событий ИБ из СЗИ и ПО (системного и прикладного) на примере настройки аудита в ОС Windows
Средства мониторинга и корреляции событий ИБ (Log Management (LM) и SIEM-системы) осуществляют сбор, агрегацию, запись, хранение, поиск, таксономию, обогащение (SIEM), корреляцию (SIEM) событий ИБ от источников.
Источники событий ИБ:
Системы управления событиями ИБ (Log Management):
Сбор/получение данных из различных источников событий ИБ
Отсутствует полноценная корреляция событий
Отсутствует дополнительный функционал
Получение журналов с разнообразных средств защиты: поддержка большого количества типов систем, проприетарных протоколов, API-запросов.
Нормализация полученных данных: преобразование данных в единообразный, пригодный для дальнейшего использования формат.
Таксономия нормализованных данных: классификация нормализованных сообщений для формирования и последующего анализа последовательности типов событий с определенным смыслом и временем наступления.
Корреляция классифицированных событий: соотнесение между собой событий, удовлетворяющих тем или иным условиям (правилам корреляции).
Создание инцидента, предоставление инструментов для проведения расследования.
Хранение информации о событиях и инцидентах в течение длительного времени (от 6 месяцев) с механизмами сжатия, оптимизации.
Быстрый поиск по хранящимся в SIEM данным.
Пример правил корреляции:
если на двух и более ПК в течение 5 минут сработал антивирус с одинаковой сигнатурой, то это вирусная атака;
если в течение 24 часов были зафиксированы чьи-то попытки удаленно зайти на сервер, которые в конце концов увенчались успехом, а затем с этого сервера началось копирование данных на внешний файлообменник, то это может свидетельствовать о том, что злоумышленники подобрали пароль к учетной записи, зашли на сервер и похищают информацию.
Характерная особенность SIEM-систем – интеграция со сторонними решениями для более комплексного анализа событий и инцидентов ИБ.
Один из типов таких решения – системы киберразведки угроз (Cyber Threat Intelligence), которые передают в SIEM-систему данные, называемые источниками Threat Intelligence (TI Feeds, или TI-фидами, источниками данных киберразведки).
TI-фиды – это набор индикаторов компрометации (Indicators of Compromise (IoC)), использование которых связано с подходом «Assumed Breach» («Считайте, что вас уже взломали») – сложное вредоносное ПО находится в инфраструктуре атакованной компании десятки/сотни дней до момента обнаружения.
Индикатор компрометации – это некий объект/артифакт, обнаруженный в ИТ-инфраструктуре компании, наличие которого с высокой долей вероятности может свидетельствовать о готовящейся, совершающейся или уже осуществленной компьютерной атаке.
Cyber Threat Hunting (поиск киберугроз) – это поиск угроз внутри сети: анализ потенциальных свидетельств атаки вирусов, поиск следов деятельности киберпреступных групп, поиск признаков заражений (руткиты/буткиты, прошивки), анализ сообщений от сторонних компаний.
Киберразведка условно разделяется на:
Стратегическую – поиск данных о потенциально опасных для защищаемой компании APT-группах, в том числе информации об их подготовке к совершению кибератаки;
Тактическую – поиск данных о тактиках, техниках и процедурах атакующих, сокращенно TTPs (Tactics, Techniques, Procedures);
Оперативную – поиск непосредственных признаков приготовления к атаке: специфических сетевых сканирований для анализа инфраструктуры и поиска уязвимостей, мошеннических входящих звонков и фишинговых писем.
Индикаторы компрометации (IoCs) могут представлять собой:
Статические объекты – хэш-суммы файлов и их имена и расположение, IP-адреса, DNS-имена серверов в сети Интернет или конкретные URL (ссылки, например на фишинговые страницы), названия веток и ключей реестра Windows, названия мьютексов (mutex, специализированный механизм синхронизации исполняемого программного кода);
Динамические объекты – определенная последовательность несанкционированных действий на атакуемой системе (это также называют индикатором атаки, Indicator of Attack (IoA)), необычное поведение учетных записей в системе, несанкционированное появление новых учетных записей (особенно высокопривилегированных), рост числа подозрительных DNS-запросов, ICMP-трафика, иных видов ранее нехарактерной сетевой активности.
Для обмена информацией об индикаторах компрометации используются Threat Intelligence фиды (TI feeds, источники получения данных киберразведки):
Список хэш-сумм вредоносных файлов;
Список IP-адресов и DNS-имен вредоносных доменов
Список URL-адресов подозрительных веб-ресурсов.
Стандарты и протоколы для получения данных киберразведки:
коммерческие центры получения данных Threat Intelligence (например, IBM X-Force Exchange, Cisco Talos и т.д.)
государственные: в РФ это ГосСОПКА (НКЦКИ) и ФинЦЕРТ (ЦБ РФ).
Реагирование на инциденты информационной безопасности
По документу NIST SP 800-61 «Computer Security Incident Handling Guide» («Руководство по обработке инцидентов компьютерной безопасности»), реагирование на инциденты ИБ состоит из нескольких взаимосвязанных процессов:
7. Пост-инцидентные действия
Предварительный этап, документальная подготовка: разработка и согласование четких, подробных и удобных политик, процедур и инструкций по реагированию. Требуется разработать сценарии реагирования (playbooks/runbooks), по которым команда реагирования будет предпринимать заранее заданные действия в зависимости от деталей инцидента. Проводить регулярные тренировки по отработке шагов, определенных в написанных документах, обучение персонала компании и команды реагирования корректным техническим и организационным действиям во время инцидента. Обеспечить команду реагирования всем необходимым программным и аппаратным обеспечением. Выполнить превентивные действия по предотвращению инцидентов (защитить сеть и устройства компании, установить СЗИ, провести обучение сотрудников основам ИБ).
Для понимания инцидента можно руководствоваться заранее определенным списком возможных типов инцидентов ИБ и перечнем признаков возможных инцидентов.
Признаки можно условно разделить на прекурсоры и индикаторы инцидентов ИБ:
Аналитик ИБ определяет, был ли зафиксированный инцидент «боевым» или это было ложноположительное срабатывание. Следует провести идентификацию и первичную обработку (триаж, англ. triage): определить тип инцидента и категорировать его. Далее определяются индикаторы компрометации, анализируется возможный масштаб инцидента и затронутые им компоненты инфраструктуры, проводится ограниченное форензик-обследование для уточнения типа инцидента и возможных дальнейших шагов по реагированию.
4. Сдерживание / локализация инцидента
Оперативная минимизация потенциального ущерба от инцидента ИБ и предоставление временного окна для принятия решения об устранении угрозы путем:
включения более строгих запретительных правил на межсетевом экране для зараженного устройства,
изоляция зараженного хоста от локальной сети компании,
отключение части сервисов и функций,
полное выключение зараженного устройства.
Проверить надежность предпринятых мер защиты, вернуть системы в нормальный режим работы, возможно, восстановив какие-то системы из резервных копий или установив и настроив их заново.
7. Пост-инцидентные действия
Проанализировать причины инцидента для того, чтобы свести к минимуму вероятность повторного аналогичного инцидента в будущем, а также оценить корректность и своевременность действий персонала и средств защиты, и, возможно, оптимизировать какие-то процедуры реагирования и политики ИБ. Использовать агрегированную базу знаний для ведения накопленного опыта реагирования.
Внутренние (выделенное структурное подразделение компании)
Внешние (коммерческие / аутсорсинговые).
SOC = технологии + процессы + сотрудники
Сценарии реагирования (playbooks/runbooks), по которым команда реагирования будет предпринимать заранее заданные действия в зависимости от деталей инцидента. Отработка сценариев, тестирование, обучение сотрудников. Настройка правил корреляции в SIEM. Настройка, оптимизация SIEM/IRP/SOAR/SGRC-систем. Взаимодействие с заказчиками для уменьшения ложноположительных срабатываний.
2. Специалист по настройке правил в системах SIEM, SOAR, IRP получает от заказчика вводные данные о работе информационных систем и затем составляет правила выявления инцидентов и реагирования на них в используемых в SOC-Центре системах. Это могут быть:
правила корреляции в системах SIEM,
правила автоматического реагирования, локализации, восстановления информационных систем при помощи SOAR и IRP решений,
сигнатуры, т.е. правила, по которым угроза должна быть обнаружена.