Во многих компаниях согласования по безопасности появляются в тот самый последний и очень неудобный момент, когда продукт почти готов, сроки уже на подходе, а на горизонте «внезапно» возникают требования регуляторов: ФСТЭК, ЦБ — или правила обработки персональных данных.
Со стороны это выглядит так, как будто к уже готовому самолету пытаются приделать еще одно крыло, которое не было заложено в конструкцию. И, естественно, эта процедура несет риски для бизнеса, так как перегружает команды, вызывает сопротивление и увеличивает Time to Market.
Но в компаниях со зрелыми процессами безопасность и регуляторика — это встроенная часть конвейера доставки или инженерной дисциплины, если угодно. Когда интеграция функции безопасности делается правильно, то безопасность превращается в конкурентное преимущество: помогает планировать масштабирование, сформировать доверие пользователей и вовремя избегать штрафов.
Почему навешенная сверху / подключенная в конце безопасность проигрывает
В компаниях, где безопасность подключают в конце, с большой вероятностью происходят такие сценарии:
- Сделали продукт (потратили ресурсы), а потом «неожиданно» выяснилось, что продукт на рынок нельзя выпускать без закрытия регуляторных требований по безопасности.
- Ревью безопасности блокирует релиз и откладывает дату выпуска новой фичи, которую уже анонсировали. Как следствие, команды начинают проводить попытки «замазать», скрыть внутренние проблемы, формируя слабоуправляемый технический долг, лишь бы не растягивать сроки релиза.
- В итоге вместо пользы регуляторика превращается в создание «закрывающих» документов, которые никто так и не читает.
Корень проблемы почти всегда один и тот же: безопасность и разработка говорят на разных языках и подключаются в работу на разных этапах.
Безопасность как архитектурный подход
Любой аудит безопасности или архитектуры начинается с ответа на вопрос «Где хранятся данные, кто имеет к ним доступ и как они защищены?».
Если потоки и репозитории данных не задокументированы или не консистентны, то о безопасности говорить рано. Это уже хаос, а не безопасность.
Для наведения порядка важно проделать следующее:
- Обозначить четкие границы ответственности и контекста сервисов: какой сервис обрабатывает PII, какой работает с платежами, какой владеет контекстом учетных записей пользователей и т. п.
- Задокументировать инфраструктуру: зоны, доверенные контуры, точки входа в сети, используемые протоколы, сетевые порты и пр.
- Задокументировать схемы потоков данных и внести их в состав архитектурной документации.
- Добавить анализ рисков в каждый ADR. Каждое архитектурное решение должно содержать ответ на вопрос «Какие риски безопасности мы имеем: какие закрываем, какие принимаем, а какие компенсируем?».
Объединение безопасности и архитектуры способствует внедрению Security by Design — подхода, когда уязвимости перестают «внезапно» всплывать при общем аудите, а выявлены и «обезврежены» инженерами еще до начала разработки.
Политики безопасности как инженерные правила
Руководители некоторых компаний путают политики безопасности с прокламацией, отделываясь размещением PDF на корпоративном портале и обучалками/пугалками для сотрудников.
Правильно выстроенная политика безопасности присутствует на всех этапах, в том числе и в процессе разработки.
Такая политика всегда включает в себя набор правил для инженеров и содержит следующий минимальный «джентльменский набор»:
- выработанные требования к логированию (стандарты логирования) и хранению логов;
- правила обработки PII, классификации данных и их учета;
- требования к шифрованию, ключам, хранению ключей и параметров для доступа к сервисам;
- требования к идентификации, аутентификации пользователей и авторизации.
Важно учесть, что политики должны быть короткими и понятными разработчику, чтобы он мог их быстро применять.
Автоматизация безопасности: главная защита от торможения разработки
Автоматизация безопасности позволяет встроить аудит в процессы разработки и получать своевременную информацию о состоянии безопасности. Это важный шаг, который позволяет избежать внезапностей.
Итак, что нужно внедрить:
- «Инфраструктуру как код», чтобы формализовать конфигурацию и проводить будущие аудиты по конкретным файлам.
- Системы автоматической проверки кода и окружения на уязвимости, содержащие статические (SAST) и динамические (DAST) проверки. Это внедрение позволит отлавливать такие уязвимости, как SQL-инъекции, переполнения буферов, неработающая аутентификация, XSS и т. п.
- Системы автоматической проверки внешних (3rd party) библиотек на уязвимости (SCA).
- Шаблоны CI/CD, покрывающие безопасность: проверка креденшиалов, секретов, зависимостей, контейнерных образов.
- Автоматическое формирование отчетности для регуляторов на основе метаданных.
Правильно выстроенная автоматизация превращает безопасность из процесса согласований в поток проверки, что положительно влияет на продукт.
Как выстраивать отношения между разработкой и безопасностью
Часто проверки безопасности рассматриваются как продолжение разработки. Это порождает задержки релизов и дополнительные расходы на доработки после аудита безопасности.
Чтобы этого избежать, можно определить для разработки следующие правила:
1. Безопасность должна стать функцией продукта
На этом этапе важно перестать воспринимать безопасность как внешний надзор и начать воспринимать как помощь. Безопасность отныне — часть логики вашего продукта, и теперь именно внедрение процедур безопасности помогает избежать регуляторных и репутационных рисков, быстрее выйти на рынок и создает конкурентное преимущество вашего бизнеса.
Новая парадигма напрямую влияет на роль CISO: он перестает быть контролером продукта и становится его адвокатом.
2. Включить офицера безопасности в команду разработки
Распространен сценарий, когда безопасник подключается на финальных стадиях, когда продукт уже почти готов. И при таком подходе безопасник обычно воспринимается лидерами продукта скорее как враг или как препятствие, поскольку его проверки в 99% случаев порождают список из десятка страниц замечаний, которые нужно исправлять, а времени до релиза в обрез.
Решением будет интеграция безопасника в команду, а не только в процесс финальных согласований. При такой схеме он формирует векторы угроз, способы противодействия им на этапе discovery. Кроме того, он участвует в последующем обсуждении и планировании архитектуры, а его задачи (в идеале) находятся в общем бэклоге с разработкой и приоритизируются вместе с другими инженерными и продуктовыми задачами.
3. Разработать SLA на проверки безопасности
Если не определить сроки выполнения проверок, то безопасность становится сдерживающим фактором.
Именно поэтому вводят SLA на активности, связанные с безопасностью. А именно:
- на ревью архитектурного решения;
- проверку изменений;
- аудит релиза.
Эти действия дают контроль над функцией безопасности.
4. Сформировать единую карту рисков
Часто единственный способ избежать мордобоя — это задать общий контекст. Безопасники и разработчики не исключение. Для предупреждения и предотвращения конфликтов создается единая карта рисков (обычно на этапе discovery), которая содержит:
- Список рисков, их классификацию. Этот список включает неочевидные риски вроде слива инсайдерской информации.
- Вероятность каждого риска и бизнес-последствия в максимальном случае.
- Стоимость устранения/исправления.
И в итоге определяется приоритет по каждому риску. Когда стоимость риска ясна и все ответственные лица в контексте, то решения по безопасности порождают конструктив.
Функция безопасности как ускоритель для бизнеса
Когда процессы организованы правильно, безопасность перестает сдерживать и открывает возможности:
- для вывода фичей на рынок быстрее, без сюрпризов в конце;
- масштабирования без штрафов от регулятора;
- новых партнерств, особенно тех, где требуются сертификации;
- повышения доверия пользователей и сохранения репутации;
- экономии.
В основном бизнесы тормозит неправильная внутренняя организация работы с безопасностью. Те компании, которые научились интегрировать процессы безопасности в архитектуру и разработку, выигрывают в скорости поставки релизов, их качестве и устойчивости. А главное — они перестают воспринимать регуляторику как обузу. Она превращается в еще одну инженерную дисциплину, регулируемую теми же правилами, что и разработка: прозрачность, автоматизация, контроль рисков и четкие договоренности.
