Знаете, как обычно проходит первая встреча с сертификацией ФСТЭК? Примерно как встреча с медведем в лесу. Все знают, что он где-то есть, все слышали истории о том, как другие его видели, но пока не столкнешься сам — не поймешь масштаба.
«Документации будет столько, что можно небольшой лес сохранить», «Год минимум, а то и полтора», «Придется выделить целую команду», «А потом еще и каждое обновление...» — такое слышишь постоянно. И когда мы только начинали, эти страшилки не казались преувеличением.
Наибольший интерес вызывала перспектива регулярных инспекций. Продукт живой — он растет, развивается. У нас продуктов целая экосистема ПО виртуализации, десяток значимых обновлений каждый год, и каждое потребует инспекционного контроля. Но в какой-то момент стало понятно: либо мы научимся проходить сертификацию и последующие проверки красиво, либо увязнем в бесконечном марафоне.
Спойлер: мы научились. Теперь сертификация ФСТЭК для нас — это не квест с неизвестным финалом, а понятный процесс с измеримыми параметрами.
В этой статье мы не будем разбирать подробно, что нужно для сертификации — публикации с детальным списком документов можно найти на Хабре. Вместо этого поделимся своим опытом, и если вы сейчас стоите перед необходимостью пройти сертификацию или хотите оптимизировать существующий процесс — надеюсь, он поможет сделать этот путь немного проще.
С чем придется иметь дело
Начнем с небольшой справки. Сертификация ФСТЭК — не просто бюрократическая формальность, а серьезная проверка безопасности продукта. И требования там, надо сказать, вполне разумные.
Допустим, ваше решение собирается использовать госорганизация или оно как-то связано с критической инфраструктурой. Либо, например, обрабатывает персональные данные. В этом случае вы точно попадаете под требование о сертификации, тут и начинается ваше приключение.
Первое, с чем предстоит столкнуться, — это уровни доверия. Их всего шесть, от первого, самого строгого, до минимального шестого. Выбор уровня — важная часть. Если взять слишком высокий, замучаетесь проходить. Кроме того, первые три — для работы со всяким секретным, и вряд ли оно вам надо. Взять слишком низкий — можете отрезать себе часть потенциального рынка. Мы, например, пошли на четвертый уровень — он позволяет работать с госсистемами первого класса защищенности и при этом не требует совсем уж хардкорных мер.
Уровень выбран, смотрим требования. Выглядят они, надо сказать, сложно и не очень приятно, но когда начинаешь разбираться, понимаешь — они логичны. И здесь важно понять вот что: к сертификации не придется готовиться КАЖДЫЙ РАЗ, если встроить ее требования в сам процесс разработки.
Итак, что происходит, когда вы решаетесь на сертификацию? Процесс состоит из нескольких последовательных этапов, каждый из которых требует отдельного внимания. Первый — выбор испытательной лаборатории из реестра ФСТЭК. Опыт лаборатории в вашей конкретной области, ее подход к коммуникации, даже географическое расположение — все это может существенно повлиять на процесс сертификации. Поэтому подойдите к выбору со всей серьезностью, обратитесь к опытным людям, изучите доступные варианты. У нас получилось не с первого раза, но в итоге мы нашли лабораторию и отличную команду.
Следующий этап — подготовка документации. Вам нужно детально описать архитектуру системы, все интерфейсы, каждую функцию безопасности. Все, что может быть задокументировано, должно быть задокументировано. Отдельного внимания заслуживает документация по процессам разработки и тестирования — здесь ФСТЭК особенно придирчив.
Затем начинается непосредственно процесс проверки. Он включает статический анализ кода, динамическое тестирование, анализ уязвимостей, проверку на недекларированные возможности. По сути, это многоуровневый аудит безопасности, который охватывает все аспекты работы вашего продукта, от архитектуры решений до конкретных реализаций функций безопасности. Первый список замечаний от лаборатории обычно состоит из нескольких сотен пунктов, и каждый требует проработки.
Например, статический анализатор находит потенциальную уязвимость в коде. Пофиксили и поехали дальше? Нет. Нужно не только исправить конкретный фрагмент кода, но и проверить, нет ли аналогичных проблем в других частях кода. А потом описать, как именно было сделано исправление, задокументировать изменения и убедиться, что они не создали новых проблем.
Следующая история — это управление зависимостями. Любая внешняя библиотека (и другое внешнее ПО) должна быть проверена и задокументирована. И если в процессе сертификации выяснится, что какая-то библиотека не проходит по требованиям безопасности, — придется либо искать альтернативу, либо писать собственное решение.
Отдельный круг ада — регулярные релизы. Каждое значимое обновление требует повторного прохождения части этих процедур. Без правильно выстроенных процессов это может превратиться в бесконечный цикл доработок и проверок, который будет тормозить развитие продукта.
Что придется сделать
Правильная организация процесса — это первое, что мешает сертификации превратиться в бесконечную борьбу с документами и проверками. У нас процесс перестройки процессов занял примерно 4–5 месяцев и очень непростых, надо отметить. Но в итоге выстроенный процесс сэкономил нам гораздо больше времени.
Выстраивание процессов
Для начала, если у вас нет отдельного подразделения технических писателей, нужно его завести. А если кто-то высказывает идею «в целях экономии» распределить задачи по документированию между разработчиками и менеджерами, киньте в него чем-нибудь: поначалу такой подход может сработать, но очень быстро превратится в головную боль для команд, а кончится все неструктурированным бардаком, на разгребание которого уйдет куча времени.
Технический писатель — это не тот, кто умеет красиво излагать мысли. В идеале это специалист, который понимает (или может разобраться), как должна выглядеть документация для регулятора, знает все требования к ее оформлению и умеет структурировать информацию так, чтобы она была понятна и разработчикам, и проверяющим. Нужны ли эти знания разработчикам? Захотят ли они тратить время на оформление документации по ГОСТу? Напишите в комментариях /s
Далее — система версионирования документации. Тут мы, кстати, прошли через несколько итераций. Сначала пытались использовать облачные сервисы вроде Nexus Cloud. Казалось, что раз документы в облаке, с ними можно всем работать одновременно... Но по факту, когда несколько человек из разных отделов начинают править один документ, изменения сохраняются криво, версии конфликтуют и в итоге приходится тратить время на перепроверку каждой правки.
В итоге пришли к локальным инструментам работы с документацией: четкое версионирование, возможность параллельной работы и, что важно, прозрачная история изменений. Теперь каждое подразделение — будь то разработка, безопасники или технические писатели — может работать со своей частью документации, не мешая друг другу.
Следующий важный шаг — формирование команды сертификации. У нас она сложилась постепенно: пока специалисты испытательной лаборатории знакомились с продуктом, мы проводили демонстрации, готовили предварительную документацию. В процессе этой работы стало понятно, какие именно специалисты нужны для сертификации и как распределить роли. В нашу команду вошли представители разработки и тестирования, DevSecOps-инженер, ИБ-специалист, технические писатели и руководитель проекта, он же лид по сертификации.
Сразу стоит сказать, что взаимодействие между командой разработки и командой сертификации нужно налаживать. Это отдельная задача, которая вряд ли решится сама собой. В нашем случае разработчики воспринимали требования сертификации как лишнюю бюрократию, отнимающую время, которое можно было бы потратить на классные фичи и развитие продукта в целом. Решение нашли в том, чтобы сделать процесс максимально прозрачным: рассказали о целях сертификации, создали четкие регламенты, прописали зоны ответственности, установили понятные дедлайны для каждого этапа.
Теперь, когда приходит время готовить новую версию к сертификации, все знают свою зону ответственности. Разработчики понимают, какие требования нужно учесть еще на этапе проектирования. Технические писатели знают, какую документацию нужно подготовить. А команда сертификации может спокойно планировать взаимодействие с испытательной лабораторией, не опасаясь, что в последний момент всплывет какой-нибудь неучтенный момент.
Безопасная разработка
Главное правило внедрения безопасной разработки, которое мы для себя вывели: начинать с малого и двигаться пошагово. Попытка сразу внедрить полный набор инструментов почти всегда приводит к перегрузке команды, которая начнет сопротивляться изменениям.
Статический анализ кода (SAST) — это база. Большинство SAST-решений — open source, их легко интегрировать в процесс разработки, и они могут работать прямо в IDE. Это, по сути, как проверка орфографии, только для кода: находит очевидные проблемы еще на этапе написания. Мы используем, например, SonarQube и Mobile Security Framework. Они помогают обнаруживать небезопасные конфигурации, открытые пароли и другие типичные ошибки в коде.
Анализ зависимостей (CSA) помогает выявить уязвимости в библиотеках, используемых приложением. Например, Dependency Check от OWASP проверяет зависимости на основе баз данных известных уязвимостей. С его помощью можно оперативно находить потенциально опасные компоненты.
Динамический анализ (DAST) — проверяем приложение в процессе работы, чтобы выявить уязвимости, которые проявляются только при исполнении кода. Тут наш любимчик — OWASP ZAP.
Интерактивный анализ (IAST) сочетает в себе функции статического, динамического и других видов анализа. Позволяет в реальном времени отслеживать потенциальные уязвимости в работающем приложении, предоставляя разработчикам четкие и понятные рекомендации по их устранению.
Вдаваться в подробности здесь не будем, о внедрении безопасной разработки мы уже рассказывали на Хабре. Однако отметим одну из важных, но не слишком очевидных вещей, — концепция независимости проверки. Проверяющий не должен оказываться под давлением команды разработчиков и не должен от нее зависеть. Желательно, чтобы он подчинялся отдельной ветке управления, а в идеале — вообще генеральному директору. Иначе возникает риск компромиссов: security-ревьювер может начать помечать уязвимости как ложноположительные или переносить их в технический долг, вместо того чтобы требовать немедленного исправления. А это уже прямой путь к проблемам при сертификации.
Мы используем подход Security Champions — это разработчики, которые выступают посредниками между командами. Они не обязательно имеют профильное образование, но готовы «вгрузиться» в вопросы безопасности. «Чемпионы» понимают и язык разработки, и требования безопасности. Когда безопасник говорит «у вас тут потенциальная RCE в legacy-коде», а разработчик отвечает «код на проде уже черт знает сколько крутится, когда проэксплуатируешь, тогда и приходи», подключается Security Champion. Его задача — донести до одной стороны позицию другой и найти компромиссное решение, которое вовсе не обязательно «где-то посередине». Главное, что в итоге один понимает сложность решения, второй понимает важность. Радость, счастье, проблема закрывается благодаря взаимодействию всех со всеми, а не через лишнюю эскалацию конфликта до руководства и многонедельную ругань.
Работа с лабораторией
Испытательная лаборатория становится вашим партнером на долгое время, поэтому правильную коммуникацию важно выстроить с самого начала. Мы сразу договорились о том, что лаборатория выделяет для нас постоянных специалистов: менеджера проекта и технических экспертов по каждому направлению. Это позволило им глубже погрузиться в специфику продукта, а нам — получать более предметную обратную связь.
Взаимодействие команды разработки со специалистами из лаборатории (и шире — с вашими DevSecOps и AppSec‑инженерами, которым тоже нужен доступ к коду) требует особого внимания. Первая реакция разработчиков обычно настороженная: кто-то будет копаться в их коде, искать проблемы, задавать неудобные вопросы. Здесь опять помогает прозрачность. Нужно рассказать, кто именно получит доступ к коду и зачем. Что эти люди — не враги и не критики, а партнеры. Что взаимодействие происходит в рабочем порядке: специалисты получают доступ к необходимым веткам и репозиториям, участвуют в обсуждении архитектурных решений на ранних этапах. Все это в итоге позволяет учесть требования безопасности и сертификации еще до начала разработки, вместо того чтобы пытаться встроить их потом в готовое решение (что создает нагрузку на тех же разработчиков).
Еще тесное взаимодействие с лабораторией помогает вовремя получать важную информацию об актуальных изменениях в законодательстве. Один раз мы были уже на финальном этапе сертификации, буквально ждали подписания документов, когда вышли новые требования к базам данных. За неделю до финала. Пришлось в экстренном порядке пересматривать архитектуру и менять базу на другую. Как говорится, старайтесь по возможности избегать этого.
С тех пор мы очень внимательно следим за всеми анонсами и проектами новых требований, а постоянное взаимодействие с лабораторией нам в этом помогает И когда готовится новая версия продукта, мы сразу проверяем, нет ли каких-то планируемых изменений в требованиях, которые могут повлиять на сертификацию.
Сделанные выводы
Пожалуй, главный урок, который мы усвоили: сертификация — это не то, к чему нужно готовиться в последний момент. Она должна быть встроена в сам процесс разработки. Поэтому мы организовали полноценный DevSecOps-конвейер и внедрили все необходимые проверки безопасности. Условно говоря, нужно создать такую среду, где небезопасный код просто не может выйти в прод. Каждый коммит проходит через несколько уровней проверки, каждое изменение автоматически документируется, каждая зависимость проверяется на уязвимости.
Получилась своего рода «кибериммунная» система — безопасность встроена в процесс на уровне архитектуры. И когда приходит время сертификации, оказывается, что большая часть требований уже выполнена просто потому, что так устроен наш процесс разработки.
Очень важно правильно распределить ответственность между командами. У нас это выглядит так:
Разработка отвечает за реализацию требований безопасности в коде;
Команда ИБ проводит аудиты и консультирует разработку;
Security Сhampions обеспечивают коммуникацию между ИБ и разработкой;
DevSecOps следит за автоматизацией процессов безопасности;
Технические писатели ведут всю документацию.
Последнее, но не менее важное: нужно выстроить процесс мониторинга изменений в требованиях регулятора. Это может быть комбинация из нескольких источников: официальные публикации ФСТЭК, информация от испытательной лаборатории, профильные конференции и сообщества. Главное — не пропустить изменения, которые могут непосредственно повлиять на продукт.
И, кстати, еще один момент: процесс выстраивания процессов может существенно ускориться, если в команде есть специалист с опытом прохождения сертификации или глубоким пониманием информационной безопасности. Такой человек смотрит на систему под тем же углом, что и регулятор, и может предвидеть потенциальные проблемы еще на этапе проектирования. По сути, это свой «внутренний аудитор», который помогает избежать типичных ошибок.
Дополнительную поддержку можно получить в сообществах, сложившихся вокруг Института системного программирования РАН. Команды проводят исследования различного ПО, в первую очередь с открытым исходным кодом, вплоть до ядра Linux. Можно объединить усилия с ними и исследовать свои версии используемых продуктов.
В общем, если вы думаете, что сертификация ФСТЭК — это про «надо перетерпеть», то да, но нет. Отношение к сертификации как к единовременному испытанию превратит каждое обновление в новый подвиг, а это вам не понравится. Если же сделать сертификационные требования частью процесса разработки — сертификация превратится просто в один из аспектов работы над продуктом.
Правильно выстроенные процессы позволяют работать на опережение. Да, периодически нужно что-то обновлять и корректировать, но это уже не авральная мобилизация всей команды, а планомерная работа. И каждый следующий цикл сертификации проходит быстрее и легче, потому что когда система уже настроена под необходимые требования, любую внезапную «донастройку» можно делать в режиме, близкому к обычному.
