Что такое компьютерный инцидент

Обновлено: 15.01.2025

Состав технических параметров компьютерного инцидента, указываемых при представлении информации в ГосСОПКА, и форматы представления информации о компьютерных инцидентах

Национальный координационный центр по компьютерным инцидентам опубликовал состав технических параметров компьютерного инцидента, указываемых при представлении информации в ГосСОПКА, а также форматы представления информации о компьютерных инцидентах. субъекты критической информационной инфраструктуры (далее – КИИ) и Национальный координационный центр по компьютерным инцидентам (далее – НКЦКИ) осуществляют информационное взаимодействие, в ходе которого субъекты КИИ уведомляют НКЦКИ о компьютерных инцидентах, произошедших на объектах КИИ.

Форматы представления информации о компьютерных инцидентах (компьютерных атаках, уязвимостях) в государственную систему обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации (далее – ГосСОПКА) в формате JSON доступны по ссылке:

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

Дополнительно, субъекты КИИ и другие владельцы российских информационных ресурсов имеют право уведомлять НКЦКИ о компьютерных атаках, зафиксированных на принадлежащих им объектах КИИ или других системах, а также уязвимостях в них. В целях унификации сведений, передаваемых в ходе информационного взаимодействия между НКЦКИ и субъектом КИИ, НКЦКИ и владельцами российских информационных ресурсов, НКЦКИ и иностранными (международными) организациями, выделяются следующие базовые категории и типы событий, по которым инициируется такое информационное взаимодействие (таблица 1).

Таблица 1 – Базовые категории и типы событий, по которым инициируется информационное взаимодействие.

Указанные категории и типы событий могут быть направлены в/от НКЦКИ в форме следующих уведомлений:

«Уведомление о компьютерном инциденте» (направляется субъектом ГосСОПКА в адрес НКЦКИ) (в таблице 2 уточняются категории и типы);
«Уведомление о признаке компьютерного инцидента» (направляется дежурной службой НКЦКИ в адрес субъекта ГосСОПКА) (в таблице 2 уточняются категории и типы);
«Уведомление о компьютерной атаке» (направляется субъектом ГосСОПКА в адрес НКЦКИ) (в таблице 3 уточняются категории и типы);
«Уведомление об уязвимости» (направляется субъектом ГосСОПКА в адрес НКЦКИ) (в таблице 4 уточняются категории и типы);
«Уведомление о признаке уязвимости» (направляется дежурной службой НКЦКИ в адрес субъекта ГосСОПКА) (в таблице 4 уточняются категории и типы).

Таблица 2 – «Уведомление о компьютерном инциденте» (направляется субъектом ГосСОПКА в адрес НКЦКИ) и «Уведомление о признаке компьютерного инцидента» (направляется дежурной службой НКЦКИ в адрес субъекта ГосСОПКА).

Таблица 3 – «Уведомление о компьютерной атаке» (направляется субъектом ГосСОПКА в адрес НКЦКИ).

Таблица 4 – «Уведомление об уязвимости» (направляется субъектом ГосСОПКА в адрес НКЦКИ) и «Уведомление о признаке уязвимости» (направляется дежурной службой НКЦКИ в адрес субъекта ГосСОПКА).

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

характер уведомления (должна быть предоставлена информация следующего вида: "Уведомление о компьютерном инциденте", "Уведомление о компьютерной атаке" или "Уведомление об уязвимости"; из НКЦКИ направляется информация следующего вида: "Уведомление о признаке компьютерного инцидента" или "Уведомление о признаке уязвимости");
категория и тип события (компьютерный инцидент, компьютерная атака или наличие уязвимости) в соответствии с установленным унифицированным перечнем (таблица 1);
дата и время выявления компьютерного инцидента (признака инцидента), начала компьютерной атаки или выявления уязвимости (признака уязвимости);
дата и время восстановления штатного режима работы контролируемого информационного ресурса (объекта КИИ) после компьютерного инцидента, окончания компьютерной атаки или устранения уязвимости;
состояние работ по реагированию на компьютерный инцидент (в зависимости от характера уведомления должна быть предоставлена информация следующего вида: "Меры приняты, инцидент исчерпан", "Проводятся мероприятия по реагированию на инцидент", "Возобновлены мероприятия по реагированию на инцидент", "Меры приняты, атака локализована", "Проводятся мероприятия по локализации компьютерной атаки", "Возобновлены мероприятия по локализации компьютерной атаки", "Меры приняты, уязвимость устранена", "Проводятся мероприятия по устранению уязвимости", "Возобновлены мероприятия по устранению уязвимости");
оценка последствий компьютерного инцидента или компьютерной атаки (должна быть предоставлена информация следующего вида: "Влияние на конфиденциальность": "Высокое", "Низкое" или "Отсутствует"; "Влияние на целостность": "Высокое", "Низкое" или "Отсутствует"; "Влияние на доступность": "Высокое", "Низкое" или "Отсутствует"; дополнительно может быть предоставлено описание иной формы последствий компьютерного инцидента или компьютерной атаки);
необходимость привлечения сил ГосСОПКА (должна быть предоставлена информация следующего вида: "Да" или "Нет");
ограничительный маркер на распространение сведений из данной карточки компьютерной атаки (должна быть предоставлена информация следующего вида: "TLP:WHITE", "TLP:GREEN", "TLP:AMBER" или "TLP:RED"; описание маркера представлено по адресу: https://www.first.org/tlp/; в случае отсутствия в уведомлении ограничительного маркера средствами технической инфраструктуры автоматически будет проставлено значение по-умолчанию "TLP:WHITE");
регистрационный номер уведомления о компьютерном инциденте (признаке инцидента), компьютерной атаке или уязвимости (признаке уязвимости), который присваивается дежурной службой НКЦКИ;
связь с другими уведомлениями о компьютерном инциденте, атаке или уязвимости (должен быть предоставлен регистрационный номер уведомления, в котором содержатся связанные с текущим событием сведения, а также тип связи: "Предшествующий инцидент, "Предшествующая атака", "Предшествующая уязвимость", "Дочерний инцидент", "Дублирует сведения об инциденте", "Дублирует сведения об атаке", "Дублирует сведения об уязвимости или недостатках конфигураций").

наименование контролируемого информационного ресурса (объекта КИИ);
наличие одной из категорий у объекта КИИ или ее отсутствие (должна быть предоставлена информация следующего вида: "Объект КИИ первой категории значимости", "Объект КИИ второй категории значимости", "Объект КИИ третьей категории значимости", "Объект КИИ без категории значимости" или "Информационный ресурс не является объектом КИИ");
целевая функция или сфера деятельности, в которой функционирует информационный ресурс (должна быть предоставлена информация следующего вида: "здравоохранение", "наука", "транспорт", "связь", "банковская сфера и иные сферы финансового рынка", "топливно-энергетический комплекс", "атомная энергия", "оборонная промышленность", "ракетно-космическая промышленность", "горнодобывающая промышленность", "металлургическая промышленность", "химическая промышленность" или "другое");
наличие подключения к сетям электросвязи (должна быть предоставлена информация следующего вида: "Да" или "Нет");
сведения о месте нахождения или географического местоположения информационного ресурса или объекта КИИ (должна быть предоставлена информация следующего содержания: алфавитно-цифровой геокод страны и его административно-территориальной единицы (для России ISO 3166-2:RU), наименование города, наименование улицы и номер здания);
наименование субъекта КИИ или владельца информационного ресурса, на котором выявлен компьютерный инцидент, компьютерная атака или уязвимость;
наименование субъекта, сообщившего о компьютерном инциденте.

IPv4-адрес (маршрутизируемый) источника вредоносной активности;
IPv6-адрес (маршрутизируемый) источника вредоносной активности;
подсеть маршрутизируемых сетевых адресов (в формате CIDR), в которой размещаются источники вредоносной активности;
доменное имя, ассоциированное с источником вредоносной активности;
URI-адрес источника вредоносной активности;
email-адрес источника вредоносной активности;
номер подставной Автономной системы (ASN);
сведения о модулях ВПО (должна быть предоставлена информация следующего содержания: значение хеш-суммы вредоносного модуля, вердикт антивирусного средства и наименование соответствующего антивирусного средства (в случае положительной сработки)).

категория уязвимого продукта (должна быть предоставлена информация следующего вида: "Операционные системы Microsoft и их компоненты", "Unix-подобные операционные системы и их компоненты", "Серверное программное обеспечение и его компоненты", "Прикладное программное обеспечение", "Компоненты рабочих станций и серверных платформ", "Телекоммуникационное оборудование", "Средства защиты информации", "Периферийное оборудование", "Промышленное программно-аппаратное оборудование", "Мобильные платформы", "IoT-устройства", "Программное и аппаратное обеспечение в сфере здравоохранение", "Программное и аппаратное обеспечение в сфере науки", "Программное и аппаратное обеспечение в сфере транспорта", "Программное и аппаратное обеспечение в сфере связи", "Программное и аппаратное обеспечение в сфере энергетики", "Программное и аппаратное обеспечение в банковской сфере и иных финансовых сферах", "Программное и аппаратное обеспечение в топливно-энергетическом комплексе", "Программное и аппаратное обеспечение в области атомной энергии", "Программное и аппаратное обеспечение в оборонной промышленности", "Программное и аппаратное обеспечение в ракетно-космической промышленности", "Программное и аппаратное обеспечение в горнодобывающей промышленности", "Программное и аппаратное обеспечение в металлургической промышленности", "Программное и аппаратное обеспечение в сфере химической промышленности");
наименование и версия (диапазон версий) уязвимого продукта;
идентификатор уязвимости в какой-либо из систем описания уязвимостей (БДУ ФСТЭК, MITRE и т.п.).

ФИО контактного лица;
полномочия контактного лица (должность или роль);
контактный телефон;
адрес электронной почты.

дата и время регистрации уведомления о компьютерном инциденте (признаке инцидента), атаке или уязвимости (признаке уязвимости) (автоматически фиксируется в технической инфраструктуре НКЦКИ);
дата и время последнего изменения сведений в уведомлении о компьютерном инциденте (признаке инцидента), атаке или уязвимости (признаке уязвимости) (автоматически фиксируется в технической инфраструктуре НКЦКИ);
технический идентификатор уведомления, автоматически генерируемый в технической инфраструктуре НКЦКИ.

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

С такими иностранными (международными) организациями субъекты КИИ должны взаимодействовать через НКЦКИ, за исключением случаев, когда прямой обмен между субъектом КИИ и такой организацией предусмотрен международным договором Российской Федерации.

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

Таким образом, субъект КИИ должен определиться с характером уведомления (инцидент, атака, уязвимость) в иностранную (международную) организацию, предоставить имеющиеся в его распоряжении технические сведения и дополнительно указать:

страну и реквизиты организации, в которую должно быть направлено «Обращение в иностранную (международную) организацию» (в свободной форме, типа поля «Комментарий»);
основание и цель отправки уведомления об инциденте/атаке/уязвимости в иностранную (международную) организацию.

НКЦКИ со своей стороны будет в установленные приказом сроки рассматривать такие обращения и предоставлять субъекту КИИ информацию следующего характера:

статус рассмотрения («Принято на рассмотрение», «Отклонено с комментарием:», «Направлено адресату»);
журнал взаимодействия с иностранной (международной) организацией (в формате чата: «вопрос-ответ», а также с возможным предоставлением файлов).

В момент утверждения Перечня необходимо вспомнить, что ФСТЭК России не единственный регулятор в области обеспечения безопасности КИИ РФ. В этой заметке расскажу о взаимоотношениях субъекта КИИ с ФСБ России.

1. Часть функций ФСБ по 187-ФЗ передано в Национальный координационный центр по компьютерным инцидентам (НКЦКИ), часть осталась за ФСБ. В рамках данной заметки нас будут интересовать только обмен информацией с НКЦКИ.

2. Информировать о компьютерных инцидентах необходимо всем субъектам КИИ, даже не владеющих значимыми объектами КИИ.

3. Информирование НКЦКИ не равно «подключение к ГосСОПКА». Субъект КИИ не обязан использовать техническую инфраструктуру НКЦКИ или устанавливать у себя технические средства ГосСОПКА.

4. ФСТЭК передает информацию обо всех объектах КИИ в НКЦКИ, включая незначимые. Но передает в момент подтверждения результатов категорирования (форма 236 Приказа ФСТЭК), а не в получения Перечня объектов, подлежащих категорированию.

Оповещение субъекта КИИ от ФСТЭК о передаче информации в ГосСОПКА Оповещение субъекта КИИ от ФСТЭК о передаче информации в ГосСОПКА

5. Сейчас ответственности за «не информирование НКЦКИ о компьютерных инцидентах» в законодательстве страны не предусмотрена. Но планируется внести изменения в КоАП и наказывать штрафом от 10 000 до 50 000 рублей и сроком давности в один год. Прокуратура уже сейчас запрашивает подтверждение выполнения субъектом КИИ требований об информировании НКЦКИ.

Субъект КИИ обязан:

« незамедлительно информировать о компьютерных инцидентах ФСБ России, а также Центральный банк РФ (в случае, если субъект КИИ осуществляет деятельность в банковской сфере и в иных сферах финансового рынка) в установленном ФСБ России порядке (в банковской сфере и в иных сферах финансового рынка указанный порядок устанавливается по согласованию с Центральным банком РФ) ;» (п.1. ч.2. ст.9 187-ФЗ)

И руководствоваться нам придется Приказом ФСБ от 24.07.2018 № 367 «Об утверждении Перечня информации, представляемой в государственную систему обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации и Порядка представления информации в государственную систему обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации»

Самый важный вопрос для субъекта КИИ, а что считать «компьютерным инцидентом»? О каком событии необходимо информировать НКЦКИ?

Ответ дан в ст.2 187-ФЗ

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

Мы видим две различных ситуации.

1. Объект КИИ – это ИС/АСУ/ИТКС. Только в случаи нарушения функционирования ИС/АСУ/ИТКС возникает компьютерный инцидент. Если проектные параметры ИС не ухудшились, то и компьютерного инцидента нет. И информировать НКЦКИ не требуется.

2. В ИС/АСУ/ИТКС обрабатывается информация. Если зафиксирован факт нарушения безопасности информации, то компьютерный инцидент и отправка информации о нем в НКЦКИ.

« Безопасность информации - состояние защищенности информации, при котором обеспечены ее конфиденциальность, доступность и целостность . »

Ключевой момент: компьютерный инцидент может быть и без компьютерной атаки на объект КИИ

« компьютерная атака - целенаправленное воздействие программных и (или) программно-аппаратных средств на объекты КИИ, сети электросвязи, используемые для организации взаимодействия таких объектов, в целях нарушения и (или) прекращения их функционирования и (или) создания угрозы безопасности обрабатываемой такими объектами информации »

Сообщать в НКЦКИ требуется о любых нарушениях функционирования объекта КИИ, даже не вызванных действиями хакеров.

Важно: У НКЦКИ и ФСБ нет полномочий трактовать что такое «компьютерный инцидент» для КИИ, у них есть полномочия указывать субъекту КИИ в каком объеме должна быть предоставлена информация о компьютерном инциденте и в каком формате, если используется техническая инфраструктура НКЦКИ.

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

Угрозы информационной безопасности - ключевые риски

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

Есть несколько основных рисков внутри корпораций и фирм:

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

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

Классификация инцидентов

Аномалии, с которыми сталкиваются предприятия можно классифицировать по следующим признакам:

Тип информационной угрозы;
Уровень тяжести инцидентов для работы организации;
Преднамеренность появления угрозы безопасности данных;
Вероятность возникновения повторного "заражения" программного обеспечения;
Нарушенные политики ИБ;
Уровень системы организационных структур, обеспечивающих работу и развитие информационного пространства;
Трудности обнаружения;
Сложность устранения выявленной угрозы, которая может нарушить сохранность ценных данных компании.

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

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

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

2. Угроза или разглашение конфиденциальной информации. Для этого нужно получить доступ к актуальному списку конфиденциальных данных.

3. Превышение полномочий определенными лицами. Речь идет о несанкционированном доступе работников к определенным ресурсам или офисным помещениям.

4. Кибератака, влекущая к угрозе безопасности. Если отмечается поражение вредоносным ПО большого количества ПК компании - то это не простая случайность. Во время проведения расследования важно определить источники заражения, а также причины данного события в сети организации.

Что делать при обнаружении инцидента?

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

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

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

Реагирование на утечку данных

При обнаружении нарушений в сети организации рекомендован следующий алгоритм действий со стороны службы информационной безопасности:

1. Фиксация состояния и анализ информационных ресурсов, которые были задействованы.

2. Координация работы по прекращению влияния информационных атак, проведение которых спровоцировало появление инцидента.

3. Анализ всего сетевого трафика.

4. Локализация события.

5. Сбор важных данных для установления причин происшествия.

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

7. Устранение последствий.

8. Контроль устранения последствий.

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

Выявление причин инцидента безопасности

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

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

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

Решения для информационной безопасности организации

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

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

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

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

Информирование об инцидентах

Перво наперво необходимо получить информацию об инциденте. Этот момент необходимо продумать ещё на этапе формирования политики безопасности и создания презентаций по ликбезу в ИБ для сотрудников.
Основные источники информации:

1. Helpdesk.
Как правило (и это хорошая традиция) о любых неполадках, неисправностях или сбоях в работе оборудования звонят или пишут в хелпдеск вашей IT-службы. Поэтому необходимо заранее «встроиться» в бизнес-процесс хелпдеска и указать те виды инцидентов, с которыми заявку будут переводить в отдел информационной безопасности.

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

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

Категорирование инцидента

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

1. Разглашение конфиденциальной или внутренней информации, либо угроза такого разглашения.
Для этого необходимо иметь, как минимум, актуальный перечень конфиденциальной информации, рабочую систему грифования электронных и бумажных носителей. Хороший пример — шаблоны документов, практически на все случаи жизни, находящиеся на внутреннем портале организации или во внутренней файлопомойке, по умолчанию имеют проставленный гриф «Только для внутреннего использования».
Немного уточню про угрозу разглашения, в предыдущем посте я описывал ситуацию, когда документ с грифом «Только для внутреннего использования» был вывешен в общем холле, смежным с другой организацией. Возможно, самого разглашения и не было (вывешено было после окончания рабочего дня, да и замечено было очень быстро), но факт угрозы разглашения — на лицо!

2. Несанкционированный доступ.
Для этого необходимо иметь список защищаемых ресурсов. То есть тех, где находится какая-либо чувствительная информация организации, её клиентов или подрядчиков. Причём желательно внести в эту категорию не только проникновения в компьютерную сеть, но и несанкционированный доступ в помещения.

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

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

5. Компрометация учетных записей.
Этот пункт перекликается с 3. Фактически инцидент переходит из 3 в 5 категорию, если в ходе расследования инцидента выясняется, что пользователь в этот момент физически и фактически не мог использовать свои учётные данные.

Классификация инцидента

С этим пунктом в работе с инцидентами можно поступить 2-мя путями: простым и сложным.
Простой путь: взять соглашение об уровне сервиса вашей IT-службы и подогнать под свои нужды.
Сложный путь: на основе анализа рисков выделить группы инцидентов и/или активов, в отношении которых решение или устранение причин инцидента должны быть незамедлительными.
Простой путь неплохо работает в небольших организациях, где не так уж и много закрытой информации и нет огромного количества сотрудников. Но стоит понимать, что IT-служба исходит в SLA из своих собственных рисков и статистики инцидентов. Вполне возможно, что зажевавший бумагу принтер на столе генерального директора будет иметь очень высокий приоритет, в том случае, как для вас важнее будет компрометация пароля администратора корпоративной БД.

Сбор свидетельств инцидента

Есть особенная прикладная наука — форензика, которая занимается вопросам криминалистики в области компьютерных преступлений. И есть замечательная книга Федотова Н.Н. «Форензика — компьютерная криминалистика». Я не буду сейчас расписывать детально аспекты форензики, просто выделю 2 основных момента в сохранении и предоставлении свидетельств, которых необходимо придерживаться.

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

После устранения инцидента

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

• переоценка рисков, повлекших возникновение инцидента
• подготовка перечня защитных мер для минимизации выявленных рисков, в случае повторения инцидента
• актуализация необходимых политик, регламентов, правил ИБ
• провести обучение персонала организации, включая сотрудников IT, для повышения осведомленности в части ИБ

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

Несколько советов

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

ГОСТ Р ИСО/МЭК ТО 18044-2007

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология. Методы и средства обеспечения безопасности

МЕНЕДЖМЕНТ ИНЦИДЕНТОВ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

Information technology. Security techniques. Information security incident management

Предисловие

1 ПОДГОТОВЛЕН Федеральным государственным учреждением "Государственный научно-исследовательский испытательный институт проблем технической защиты информации Федеральной службы по техническому и экспортному контролю" (ФГУ "ГНИИИ ПТЗИ ФСТЭК России") и обществом с ограниченной ответственностью "Научно-производственная фирма "Кристалл" (ООО "НПФ "Кристалл") на основе собственного перевода на русский язык англоязычной версии международного стандарта, указанного в пункте 4

2 ВНЕСЕН Управлением технического регулирования и стандартизации Федерального агентства по техническому регулированию и метрологии

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК ТО 18044:2004* "Информационные технологии. Финансовые услуги. Рекомендации по информационной безопасности" (ISO/IEC TR 18044:2004 "Information technology - Security techniques - Information security incident management", IDT).

* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - Примечание изготовителя базы данных.

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

5 ВВЕДЕН ВПЕРВЫЕ

6 ПЕРЕИЗДАНИЕ. Апрель 2020 г.

Введение

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

- обнаружению, оповещению об инцидентах информационной безопасности и их оценке;

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

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

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

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

1 Область применения

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

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты. Для датированных ссылок применяют только указанное издание ссылочного стандарта, для недатированных - последнее издание (включая все изменения).

ISО/IEC 13335-1:2004, IT Security techniques - Management of information and communications technology security - Part 1: Concepts and models for information and communications technology security management (Информационная технология. Методы обеспечения безопасности. Управление безопасностью информационных и телекоммуникационных технологий. Часть 1. Концепция и модели управления безопасностью информационных и телекоммуникационных технологий

ISО/IEC 17799:2000, Information technology - Code of practice for information security management (Информационная технология. Практические правила управления информационной безопасностью)

3 Термины и определения

В настоящем стандарте применены термины по ГОСТ ИСО/МЭК 13335-1, ИСО/МЭК 17799, а также следующие термины с соответствующими определениями.

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

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

3.2 событие информационной безопасности (information security event): Идентифицированное появление определенного состояния системы, сервиса или сети, указывающего на возможное нарушение политики ИБ или отказ защитных мер, или возникновение неизвестной ранее ситуации, которая может иметь отношение к безопасности.

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

Примечание - Примеры инцидентов ИБ приведены в разделе 6.

3.4 группа реагирования на инциденты информационной безопасности (ГРИИБ) [Information Security Incident Response Team (ISIRT)]: Группа обученных и доверенных членов организации.

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

4 Общие положения

4.1 Цели

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

- события ИБ должны быть обнаружены и эффективно обработаны, в частности определены как относящиеся или не относящиеся к инцидентам ИБ;

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

- идентифицированные инциденты ИБ должны быть оценены, и реагирование на них должно быть осуществлено наиболее целесообразным и результативным способом;

- воздействия инцидентов ИБ на организацию и ее бизнес-операции необходимо минимизировать соответствующими защитными мерами, являющимися частью процесса реагирования на инцидент, иногда наряду с применением соответствующих элементов плана(ов) обеспечения непрерывности бизнеса;

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

4.2 Этапы

Для достижения целей в соответствии с пунктом 4.1 менеджмент инцидентов ИБ подразделяют на четыре отдельных этапа:

1) планирование и подготовка;

Примечание - Этапы менеджмента инцидентов ИБ аналогичны процессам модели PDCA, используемой в международных стандартах ИСО 9000 [4] и ИСО 14000 [5].

Основное содержание этих этапов показано на рисунке 1.

Рисунок 1 - Этапы менеджмента инцидентов ИБ

4.2.1 Планирование и подготовка

Эффективный менеджмент инцидентов ИБ нуждается в надлежащем планировании и подготовке. Для обеспечения эффективности реакции на инциденты ИБ необходимо:

- разработать и документировать политики менеджмента инцидентов ИБ, а также получить очевидную поддержку этой политики заинтересованными сторонами и в особенности высшего руководства;

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

реагирования на инциденты ИБ");

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

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

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

- тщательно тестировать систему менеджмента инцидентов ИБ.

Этап "Планирование и подготовка" - в соответствии с разделом 7.

4.2.2 Использование системы менеджмента инцидентов информационной безопасности

При использовании системы менеджмента инцидентов ИБ необходимо осуществить следующие процессы:

- обнаружение и оповещение о возникновении событий ИБ (человеком или автоматическими средствами);

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

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

- немедленно, в реальном или почти реальном масштабе времени;

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

- если инциденты ИБ не находятся под контролем, то выполнить "антикризисные" действия (например, вызвать пожарную команду/подразделение или инициировать выполнение плана непрерывности бизнеса);

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

Читайте также: