Всем привет, это снова я — Сторож Алексей, ведущий консультант AKTIV.CONSULTING! И, перед тем как продолжить, напомню — данный текст является продолжением большой статьи, в связи с чем я настоятельно рекомендую сперва ознакомиться с первой ее частью, где я рассказывал почему и кому ГОСТ 57580.1 вновь скоро станет актуальным, а также объяснил, как Банк России (БР) видит защиту информации в финансовых организациях (ФО).
В этой же части статьи мы продолжим говорить про ГОСТ 57580.1, но теперь о том, как подойти к внедрению организационных и технических мер на практике, как и с чего следует начать и как подготовиться к внешнему аудиту.
Первое планирование
Ранее мы разобрали всю картину целиком, как строить ИБ с точки зрения ее управления и обеспечения по ГОСТ. Подробнее разберем то, с чего необходимо начать — самое первое планирование.
1) Определение области применения
Область применения — это перечень объектов и ресурсов доступа, подпадающих под требования, наш контур защиты (он же скоуп). Подход к определению области будет отличаться для ФО и подрядчиков.
Для определения области применения ФО нужно отталкиваться от автоматизированных систем и приложений (АС), которые обрабатывают информацию и (или) участвуют в технологических процессах, защита которых регулируется Положениями БР. После чего необходимо определить инфраструктуру, которая обеспечивает работу или с которой осуществляется доступ в АС, на уровнях ниже:
ОС (учитывая контейнерные), СУБД, серверы приложений,
серверные компоненты виртуализации и инфраструктурные сервисы,
сетевые приложения и сервисы,
аппаратное обеспечение.
Примечание: ФО вроде банков могут иметь широкий набор АС, защита которых регулируется разными Положениями БР. Хоть ГОСТ и поддерживает подход с выделением нескольких контуров, зачастую на практике изолировать их полностью задача весьма нетривиальная, а потому рекомендую объединять все такие АС в общий контур защиты по ГОСТ.
Особенностью подрядчиков на данном этапе будет являться то, что у них нет собственных АС, защита которых регулируется Положениями БР. Так, продолжая общую логику, в контур защиты ГОСТ необходимо выделить всю инфраструктуру (в разрезе уровней, приведенных ранее), с помощью которой осуществляется логический доступ или на которой размещаются АС ФО.
Итоговый перечень объектов и ресурсов доступа, входящих в область применения мер ГОСТ, должен быть регламентирован, но мы к этому еще вернемся.
2) Выбор мер
В российском законодательстве понятие «выбор меры» является спецификой серии ГОСТ 57580, от чего часто возникают вопросы: с одной стороны, выбор меры это не то же самое, что ее реализация (вроде бы нам достаточно регламентировать то, что мы собираемся ее выполнять), с другой — внешний аудитор не поставит нам оценку за выбор, если мы не предоставим ему свидетельства фактического применения меры.
И все же, переводя текст ГОСТ на простой язык, для выбора мер необходимо:
ознакомиться со всеми мерами, применимыми к нашему УЗ,
убрать из них меры, которые не применимы к нашей инфраструктуре (например, мы не используем Wi-Fi, а значит и меры по его защите мы не выбираем или — у нас единый контур ГОСТ, а значит неприменимы все меры по изоляции контуров между собой и так далее),
регламентировать получившийся набор мер,
отметить какие из мер уже реализованы («выбраны») в компании,
рассмотреть возможность реализации «не выбранных» мер и запланировать их на будущее — сроки, ответственные, бюджеты,
если нельзя реализовать меру напрямую (например, в legacy АС отсутствует необходимый функционал) — подумать, чем компенсировать,
вписать для каждой меры статус: выбрана / не выбрана / запланирована / компенсирована.
3) Регламентация и запуск процессов
Следующим шагом необходимо регламентировать порядок применения выбранных мер, т.е. описать то, как выбранные меры должны быть реализованы на практике (важно не забыть и о технических мерах). Сперва стоит определиться с подходом:
А) Каждый процесс обеспечения ИБ — это самостоятельный документ (положение/регламент). Классический вариант.
Б) Почти все регламентировано в едином документе, известном в мире ИБ как «ведомость применимости». Именно этот вариант я бы рекомендовал подрядчикам и новым компаниям.
Понятие такой «ведомости» (Statement of Applicability или «Заявление о применимости») приходит к нам оттуда же, откуда и PDCA — из ISO 27001. В классическом варианте этот документ содержит область применения требований и сам перечень требований (тех самых выбранных мер) — я предлагаю убить всех зайцев одновременно, добавив сюда же информацию о том, как именно выбранные меры выполняются и многое другое. Назовем наш документ, например, «Положение о выборе и порядке реализации мер ГОСТ 57580.1» и отразим в нем:
1) Описание документа, цели, термины и пр.
2) Область применения — перечень АС и инфраструктуры из контура.
3) Основная таблица с мерами:
a. № меры — условное обозначение из ГОСТ,
b. Содержание — текст меры из ГОСТ,
c. Статус — выбрана (если уже реализовали) / запланирована (планируем реализовать) / не выбрана (не планируем реализовывать) / не применима (не требуется к реализации) / компенсируется (невозможно реализовать, используются иные дополнительные меры),
d. Порядок реализации / срок планирования / обоснование неприменимости,
e. Ответственное подразделение.
Пример заполнения:
4) Описание компенсирующих мер
Форма и пример заполнения:
5) Положения о контроле (КЗИ) и совершенствовании — кто и как часто должен проводить проверку всего, что мы написали, а также на основании чего и в каком порядке этот документ должен пересматриваться.
6) Положения об ответственности и необходимости ознакомления — ИБ ответственна за контроль всех мер, а вот за реализацию — подразделения, указанные в таблице (дополнительно все равно потребуются приказы с конкретными ФИО для мер РЗИ).
Подобное положение будет является универсальным и закрывает большинство мер ГОСТ из планирования, контроля и совершенствования. Также такой документ будет самой настоящей палочкой-выручалочкой при проверке от БР или внешнем аудите. Его демонстрация на этапе выбора компании для внешней оценки соответствия может даже снизить итоговую стоимость аудита, поскольку проверяющему останется лишь перепроверить все, что вы написали, а не выяснять как у вас что реализовано самому.
Для корректного первичного заполнения я все же рекомендую провести хотя бы раз внешний аудит. Конечно, это не обязательно, если у вас есть экспертиза и ресурсы внутри команды, однако на практике это исключительная редкость.
Техническое обеспечение
Мы выбрали меры, сделали документы… но все это имеет мало значения без технической защиты. Пройдемся по всем наложенным техническим средствам, которые требует ГОСТ для каждого из УЗ.
3. Минимальному УЗ — минимальный набор:
классический межсетевой экран для выделения всех необходимых сегментов в отдельные VLAN, формирования ACL,
средство резервного копирования — бэкапим данные, конфигурации, снапшоты ВМ, в общем, весь контур,
криптошлюз (VPN) — туннелируем все внешние каналы связи,
AntiSPAM и почтовый антивирус — защищаем внешний почтовый сервер,
еще два антивируса разных производителей — один для АРМ, другой для серверов.
2. Для соответствия стандартному УЗ потребуется добавить:
NGFW с IPS, потоковым антивирусом и фильтрацией пакетов по L7 на борту, эти модули необходимо настроить на трафик между всеми сегментами внутри контура и на его границе,
WAF и AntiDDoS для защиты от атак на внешние ресурсы,
сканер уязвимостей, который, помимо классических audit, inventory и pentest, имеет режим сканирования compliance для автоматизации анализа соответствия фактических настроек заданным стандартам конфигурации,
антивирус для банкоматов и терминалов,
DLP с агентской схемой для контентного анализа всех каналов: почта, интернет, МНИ, печать,
2FA — на любом шаге пути эксплуатационного персонала до администрирования (чем «левее», тем лучше),
SIEM — организовываем мониторинг всех событий, а также реализуем многие другие меры с его помощью,
CMDB/SGRC для учета активов,
DAG для учета сетевых хранилищ,
средство для размагничивания дисков может быть отдано на аутсорс (как и все остальное),
MDM для ноутбуков и прочих устройств, с которых планируется удаленный доступ.
1. Для усиленного УЗ необходимо же будет дополнительно реализовать все ранее перечисленное в отказоустойчивой архитектуре, а также внедрить:
2FA уже для всех работников,
IDM для автоматизации контроля учетных записей,
средства доверенной загрузки на АРМ,
средство для контроля целостности резервных копий и ПО АРМ,
средство защиты виртуализации для контроля целостности запускаемых базовых образов.
И да, не забудем, что на каждое СЗИ необходим свой пакет рабочей документации согласно PDCA. Важно: описательные инструкции от вендора не подойдут, это должны быть внутренние документы с конкретными указаниями и настройками. Из положительных моментов — на этапе внедрения можно поручить это дело интегратору.
А все ли СЗИ строго обязательны? Как я говорил ранее, ГОСТ оперирует тем, что организации самостоятельно «выбирают» меры защиты. Для организаций 2 и 1 УЗ существует необходимый уровень, который нужно показать на внешней оценке — грубо говоря, соответствовать ГОСТ минимум на 86%. Так что ответ — нет. Необходимость внедрения СЗИ для соответствия ГОСТ нужно рассматривать через то, сколько мер оно покроет и какой вклад это внесет в общую оценку.
Часто 20% усилий дают 80% результата, так и здесь — наша задача набрать необходимый уровень минимальными силами, именно поэтому мы начинали с планирования и разработки документации, а дорогостоящие СЗИ мы временно аккуратно кладем в корзину тех нереализованных 14%.
Заключение
Мы выбрали меры, написали документы, внедрили или запланировали внедрять СЗИ. Что дальше? Снова вспоминаем цикл PDCA: с планированием покончено, а значит остается запустить и поддерживать реализацию, проводить контрольные мероприятия и ежегодное совершенствование системы защиты информации. Тезисно о том, как это делать смотри в первой части статьи.
Однако есть еще кое-что:
для ФО с 2 и 1 УЗ необходимо будет периодически подтверждать свое соответствие ГОСТ внешнему лицензиату ФСТЭК для отчетности перед БР,
подрядчику, чтобы получить сертификат соответствия для работы с ФО, также понадобится внешний аудит.
Что для этого потребуется:
выделить человека, который будет сопровождать весь аудит (ИБ-compliance менеджер, методолог или кто-угодно другой),
предоставить все необходимые документы по ИБ,
заполнять опросные листы и/или назначать интервью администраторам инфраструктуры и работникам, ответственнымза применение мер ГОСТ — у них спросят все то, что написано в нашем Положении,
собирать скриншоты и логи, подтверждающие выполнение мер (перенаправлять запросы от аудитора к исполнителям и собирать свидетельства для ответа).
Чего требовать от отчета:
четкого указания области оценки (применения),
для ФО — указания всех применимых Положений БР,
указания методики оценки (ГОСТ Р 57580.2),
всех необходимых, согласно методике, таблиц,
объективности, а не конкретных оценок,
качественных и подробных рекомендаций по устранению выявленных недостатков.
Как упростить себе жизнь:
минимизировать область применения, особенно подрядчику: выделить действительно изолированный контур защиты — виртуальные рабочие места (VDI) в отдельной сети, терминальные серверы и так далее — чем меньше область, тем меньше применимых требований,
собирать свидетельства заранее: набиваем базу необходимых подтверждений в рамках внутренних аудитов,
проводить комплексный аудит: если вам так или иначе нужно привлекать внешнюю оценку соответствия/эффективности в рамках различных требований (ГОСТ, ПДн, КИИ, PCI DSS), найдите компанию, способную выдать несколько отчетов после единого обследования,
не делайте фиктивных отчетов: «липовые» отчеты видно невооруженным взглядом, а значит все равно заставят переделывать нормально (например, БР требует указывать цену аудита в форме отчетности и ставит на карандаш всех, у кого аудит получился подозрительно дешевым),
если вы ФО, то попросите аудитора дополнительно сверстать вам форму отчетности для БР в формате.xls или.xml (например, для импорта в ПО Дельта), чтобы самим не тратить на это кучу времени.
Ну вот и все! Теперь вы готовы читать, осмыслять и внедрять ГОСТ Р 575780.1. Пишите понравилась ли вам статья, какие темы интересно было бы раскрыть подробнее в отдельных статьях, а также с удовольствием отвечу на вопросы в комментариях.
