NIST Cybersecurity Framework как язык между ИБ и руководством
Что даёт первая версия NIST CSF и почему это прежде всего инструмент управления рисками, а не технический стандарт.
В феврале этого года NIST опубликовал первую версию Cybersecurity Framework. Документ готовился по поручению президентского указа о защите критической инфраструктуры, но быстро вышел за пределы этой аудитории. Сейчас его читают и применяют компании, которые никакого отношения к критической инфраструктуре не имеют.
Причина проста: фреймворк решает проблему, которая есть почти в каждой компании - отсутствие общего языка между специалистами по информационной безопасности и руководством.
В чём проблема с текущим разговором
Типичный разговор об информационной безопасности на уровне совета директоров выглядит одним из двух способов. Либо это технический монолог, после которого у руководителей нет ни понимания, ни возможности принять решение. Либо это разговор "всё хорошо, мы защищены", который ничего не говорит о реальном уровне риска.
В обоих случаях руководство лишено возможности осмысленно управлять этим риском - потому что нет ни структуры, ни метрик, ни способа сравнить "где мы сейчас" с "где нам нужно быть".
NIST CSF пытается решить именно это.
Что такое NIST CSF
Фреймворк строится вокруг пяти функций: Identify, Protect, Detect, Respond, Recover - по-русски это примерно "Определить, Защитить, Обнаружить, Среагировать, Восстановиться".
Каждая функция разбита на категории и подкатегории. Для каждой есть уровни зрелости - от "неформального, реактивного" до "адаптивного, основанного на данных".
Ключевое: это не технический стандарт. Это язык для описания состояния безопасности в терминах, понятных за пределами ИТ-отдела. "Мы хорошо защищаем, но у нас нет нормального процесса обнаружения инцидентов" - это высказывание, которое менеджер может понять, оценить и включить в приоритеты.
Как это работает на практике
Применение фреймворка обычно начинается с создания "Current Profile" - честного описания того, что делается сейчас по каждой функции. Затем создаётся "Target Profile" - описание желаемого состояния с учётом рисков бизнеса и ресурсов.
Разрыв между профилями - это план работы. Он может выражаться в приоритетах, бюджетах, конкретных проектах. Главное, что он привязан к бизнес-рискам, а не к техническим требованиям ради самих технических требований.
Это отличается от классического подхода "вот список требований, выполни всё" тем, что позволяет принимать обоснованные компромиссы: "вот три вещи, которые мы делаем в первую очередь, потому что они закрывают наибольший риск при наших ресурсах."
Что CSF не решает
Фреймворк - это структура, а не готовые ответы. Он не скажет, что именно делать в вашей конкретной ситуации. Он создаёт рамку для диагностики и разговора.
Кроме того, самодиагностика имеет ограничения. Команда, которая оценивает свою же зрелость, склонна к систематическому завышению. Внешняя оценка даёт другую точность.
И наконец, фреймворк работает, только если разговор о безопасности реально происходит на уровне принятия решений. Документ, заполненный ради галочки, ничего не меняет.
Практический вопрос
Есть один простой тест: если завтра в компании произойдёт серьёзный инцидент - утечка данных, атака на инфраструктуру - знает ли руководство, что делать в первые два часа? Есть ли план реагирования? Кто принимает решения?
Если ответа нет - "Respond" в модели CSF - это первый раздел, с которого стоит начать разговор.