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

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

Определение, компоненты и понятия угрозы ИБ, события ИБ и инцидента ИБ

Углубимся в теорию.

Информационная безопасность (ИБ) — это сохранение целостности, конфиденциальности и доступности информации.

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

Чаще всего типы угроз ИБ классифицируют следующим образом:

1. Угрозы конфиденциальности — незарегистрированные пользователи получают доступ к охраняемой информации.
2. Угрозы целостности — пользователи случайно или злонамеренно изменяют или удаляют информацию.
3. Угрозы отказа в обслуживании — злоумышленники саботируют доступ к охраняемой информации.

Подробнее об этом читайте в нашем материале «Угрозы информационной безопасности».

Событие ИБ, как правило, предшествует инциденту. Это состояния системы, службы или сети, указывающее на возможное нарушение политики безопасности, отказ мер безопасности или ранее неизвестную ситуацию, которая может иметь отношение к кибербезопасности.

Событие ИБ может возникнуть один раз или повторяться. Характер события, вероятность и последствия могут быть известны не полностью.

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

Некоторые события перерастут в инциденты.

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

Понятие инцидента информационной безопасности зафиксировано во многих нормативно-правовых актах и стандартах, например, ISO/IEC 27035-1, ГОСТ Р 59709—2022, ГОСТ Р 53114—2008, ISO 27000, NIST 800-61 и проч.

Чаще всего под инцидентом ИБ подразумевают одно или несколько непредвиденных или нежелательных событий, которые вместе указывают на то, что системы или данные организации могли быть скомпрометированы или что меры защиты не дали результата. Сюда входят любые преднамеренные или непреднамеренные инциденты, создающие повышенную угрозу ИТ-безопасности.

Инцидентами могут быть:

• нарушения политик, правил или рекомендаций ИБ;
• различные ошибки пользователей;
• незарегистрированные, незапланированные изменения системы;
• нарушения правил доступа;
• системные сбои, сбои и ошибки в работе ПО и технических средств;
• утеря устройств, носителей и проч.

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

Классификация инцидентов ИБ по типам и степени критичности

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

Примеры нежелательных явлений по стандарту ISO/IEC 27035-1:

• заражение вредоносным кодом;
• нарушение политик ИБ;
• распространение информации с неприемлемым содержимым;
• сбор информации и проч.

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

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

Управление инцидентами ИБ

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

Цель — минимизировать ущерб для организации от утечек данных, взломов, системных сбоев, кибератак и проч.

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

Наиболее популярная схема управления описана в стандарте NIST SP 800-61 и выглядит следующим образом:

1. Подготовка систем и процедур. На первом этапе подготовки вы проверяете существующие меры и политики безопасности, чтобы определить их эффективность. Также на этом этапе вы совершенствуете существующие политики и процедуры или пишете новые, если у вас их нет. Эти процедуры включают план коммуникации и распределение ролей и обязанностей во время инцидента.
2. Выявление и анализ инцидентов. В стандарте NIST это самый значительный этап, на котором проводятся мониторинг, выявление, анализ, приоритизация инцидентов, выявление прекурсоров (признаков того, что может случиться в будущем) и индикаторов (данные, показывающие, что атака произошла или происходит сейчас) и оповещение ответственных лиц. Анализ включает в себя определение базовой или нормальной активности затронутых систем, корреляцию связанных событий и определение того, отклоняются ли они от нормы и если да, то каким образом.
3. Локализация, нейтрализация и ликвидация последствий. На третьем этапе проводятся локализация, сбор, хранение и журналирование инцидентов, а также ликвидация последствий. Цель нейтрализации — устранить происшествие до того, как оно истощит ресурсы системы или нанесет ущерб. Цель ликвидации может включать в себя идентификацию всех затронутых хостов, удаление вредоносного ПО, а также закрытие или сброс паролей для взломанных учетных записей пользователей.
4. Методическая деятельность. На завершающем этапе создают сводки по происшествиям, заполняют базы знаний, а также принимают организационные и технические меры.

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

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

Выявление инцидентов ИБ

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

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

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

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

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

Реагирование на инциденты ИБ

Состоит из 4-х этапов.

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

Выявление и анализ последствий. Последствиями могут быть:

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

Выявленные последствия должны быть проанализированы и ликвидированы ответственными лицами.

Ликвидация последствий. На этом этапе реагирования следует устранить негативные последствия: восстановить удаленные или измененные документы, восстановить настройки и проч.

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

Анализ. На финальном этапе реагирования следует проанализировать данные, необходимые для расследования:

• дампы трафика;
• переписки с фактом передачи информации;
• снэпшоты машин и проч.

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

Реагирование на инциденты ИБ в рамках DLP-системы

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

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

DLP-система SecureTower уже 14 лет обеспечивает информационную безопасность компаний в 20 странах мира.

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

Именно политики безопасности в DLP-системе определяют, какое событие ИБ является инцидентом, а какое можно считать незначительным.

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

• цели и задачи политики безопасности;
• условия применения политики и возможные ограничения;
• права доступа каждого сотрудника, привилегии, меру ответственности за нарушение правил ИБ;
• порядок действий в случае возникновения инцидентов информационной безопасности.

В DLP-системе SecureTower предустановлены политики и правила безопасности, при этом функционал ПО дает возможность настроить пользовательские, если есть такая потребность. Например, система может автоматически заблокировать передачу документа с меткой конфиденциальности и оповестить об этом ответственных лиц, если это было настроено в системе.

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

Превентивные меры против возникновения инцидентов ИБ

Любые нежелательные события указывают на слабые места в системе безопасности.

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

Документ, описывающий основы систем менеджмента ИБ, это ISO/IEC 27000:2018. Разработан Международной организацией по стандартизации (ISO) и Международной электротехнической комиссией.

Согласно документу, для упреждения рисков ИБ организации должны:

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

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

Цель создания СМИБ — сократить время на выявление, реагирование и ликвидацию инцидента.

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

Система менеджмента необходима как в госучреждениях, так и в небольших частных компаниях. Требования и рекомендации к СМИБ описаны в стандартах ISO/IEC 27006, ISO/IEC 27009, ISO/IEC 27001 и др.

Аудит соблюдения стандартов и требований законодательства

Предприятия, использующие СМИБ, должны подтвердить это сертификацией.

Стандарты ISO/IEC 17021 и ISO/IEC 27001 устанавливают требования и дают рекомендации органам, которые проводят аудиты и сертификации.

Для получения сертификата соответствия стандарту следует провести аудит принятых мер для управления инцидентами ИБ.

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

Аудит нужно проводить как минимум один раз в шесть месяцев. В ходе аудита следует:

• проанализировать инциденты ИБ за прошедший период;
• обновить список событий, которые можно назвать нежелательными;
• обновить или доработать список мер реагирования.

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

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

Ликвидация последствий инцидента ИБ

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

• определить причины происшествия, установить слабые места системы защиты;
• выявить виновных и соучастников, установить мотивы нарушения правила безопасности;
• сформировать отчет.

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

Методическая деятельность по инцидентам

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

В ходе проверки обсудите следующие вопросы:

1. Что произошло и когда?
2. Насколько хорошо сработала группа реагирования?
3. Были ли приняты документированные меры?
4. Были ли эти меры достаточными?
5. Какой информации не хватало?
6. Что препятствовало?
7. Что можно было сделать иначе?
8. Что можно сделать, чтобы предотвратить будущие инциденты?
9. Какие прекурсоры, индикаторы и признаками компрометации можно искать в будущем?

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

В заключение

Сотрудники часто умышленно или случайно нарушают правила ИБ, что приводит к утечкам охраняемой информации, передаче паролей киберпреступникам и др.

DLP-система существенно сокращает риски возникновения внутренних угроз ИБ. Попробуйте бесплатно 30-дневную версию SecureTower, чтобы найти и устранить слабые места вашей системы безопасности, предотвратить утечки данных по вине сотрудников, проанализировать риски ИБ, а также оценить вовлеченность ваших специалистов в процессы в течение рабочего дня.