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

ИБ

Портал для специалистов по информационной безопасности. Новости, нормативная правовая и справочная документация. Шаблоны документов.

  • Главная
  • Новости
  • НПА
    • Стандарты и методики
    • Приказы ФСБ России
    • Приказы ФСТЭК
  • Загрузки
Вы читаете: Лабиринт малотавра: Безопасность КИИ: взаимодействие с НКЦКИ
Поделиться
Aa

ИБ

Портал для специалистов по информационной безопасности. Новости, нормативная правовая и справочная документация. Шаблоны документов.

Aa
Поиск
  • Главная
  • Новости
  • НПА
    • Стандарты и методики
    • Приказы ФСБ России
    • Приказы ФСТЭК
  • Загрузки
Follow US
ИБ > Информационная безопасность > Лабиринт малотавра: Безопасность КИИ: взаимодействие с НКЦКИ
Информационная безопасность

Лабиринт малотавра: Безопасность КИИ: взаимодействие с НКЦКИ

3 года назад Просмотров: 20 3 года назад минут на прочтение: 5
Поделиться

[ad_1]

Это еще один часто задаваемый вопрос, причем от словосочетания «подключиться к ГосСОПКА» у меня уже глаз начинает дергаться. С огромным уважением отношусь к
Алексею Комарову, и в целом согласен с его выводами. Но есть пара моментов, которые не могу не прокомментировать.

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

  • вы обязаны об этом инциденте сообщить в НКЦКИ (статья 9 п. 3 ФЗ-187);
  • вы обязаны на этот инцидент отреагировать в порядке, установленном ФСБ(там же, статья 9 п. 2);
  • а для того, чтобы суметь все это проделать, вы еще раньше должны были создать систему защиты, соответствующую требованиям ФСТЭК.

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

Итак, в подразделение ИБ поступила информация (от SIEM или от пользователей) о возможном инциденте. Эта информация перепроверяется, и если факт инцидента подтвержден, субъект информирует НКЦКИ. Дальше по обстановке:

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

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

Безусловно, такие сообщения можно передавать и голосом по телефону, и на бумаге, и по электронной почте, но опять есть несколько «но»:

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

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

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

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

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

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

Второй момент, который меня резанул в отчете блогеров о встрече в ФСТЭК — фраза «у нас в стране всё теперь средства ГоСОПКА«. Не знаю, обсуждался ли на встрече контекст, в котором эта фраза была сказана изначально, но отчеты этот контекст не передают. Об этом — в следующий раз.

[ad_2]

Источник

Вас может заинтересовать

Вводятся в действие рекомендации по стандартизации Р 1323565.1.043–2022

Вступает в действие ГОСТ Р 70262.1-2022

ИБ для чайника. Часть 1.

Лабиринт малотавра: Как мы моделируем угрозы. Часть 3: техники и тактики

Лабиринт малотавра: Как мы моделируем угрозы. Часть 2: негативные последствия, угрозы, техники

Александр Демидов 11.08.2019
Предыдущая статья Аппарат УЗИ как объект критической инфраструктуры
Следующая статья Значимые объекты КИИ в банках
Комментировать

Добавить комментарий Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Вас может заинтересовать:

Вводятся в действие рекомендации по стандартизации Р 1323565.1.043–2022

4 недели назад

Вступает в действие ГОСТ Р 70262.1-2022

4 недели назад

ИБ для чайника. Часть 1.

2 года назад

Лабиринт малотавра: Как мы моделируем угрозы. Часть 3: техники и тактики

3 года назад

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

Все данные на сайте представлены для ознакомления и носят исключительно информационный характер. Администрация сайта не несёт ответственность за использование размещённой на сайте информации.

Сайт не является СМИ.

Top.Mail.Ru

© Ассоциация специалистов по информационной безопасности в сфере здравоохранения

Removed from reading list

Undo
Go to mobile version
С возвращением!

Авторизуйтесь для продолжения

Забыли пароль?