Раз-два – и в новости

Пока я пишу этот текст, взмыленные безопасники всего мира патчат существующие решения, R&D огромного количества компаний, в том числе и вендоров кибербезопасности, гневно машут кулаками на рабочих совещаниях на тему «как же мы это допустили». А злоумышленники считают деньги в своих карманах, с удовольствием рассматривая списки взломанных серверов через опубликованные в начале декабря проблемы в библиотеке log4j, устанавливая в инфраструктуру корпоративного мира криптомайнеров, шифровальщиков, ботов.

В день, когда вы читаете эти строки, мир немного выдохнул после новогодних и рождественских празднеств и снова взялся за старое – наступать на те же грабли инфобезопасности, как и раньше. И поскольку на log4j полагаются сотни и тысячи широко используемых бизнес-продуктов, включая приложения ИТ-безопасности, неспешный патчинг на местах может привести к заражению огромного количества устройств по всему миру.

2021 год, помимо прочего, запомнился бизнес-рынкам нереально сильной волной сокращений так называемого периода Go-to-Мarket, когда в установленные сроки должны выходить новые продукты. В идеале надежная стратегия Go-to-Market повышает осведомленность о рынке и гарантирует, что вы не потеряете кучу денег, времени и ресурсов в процессе вывода на рынок ненужного продукта. Однако пандемия, значительный переход покупательских процессов в онлайн и усиленная мотивация завоевания новых рынков вкупе с ростом удаленной работы и повышением спроса на классический DevOps, включая повсеместное перемещение внешней разработки в «инхауз», привели к тому, что принцип «раз-два – и в продакшн» стал использоваться в бизнесе повсеместно: в новых продуктах, в инфраструктурных блоках, в веб-приложениях – в общем, везде. Классический DevOps породил новый тренд на безопасность, однако до внедрения повсеместно принципов SecDevOps еще очень далеко.

Что делать здравомыслящему бизнес-руководителю или R&D-директору, не желающему читать про себя страсти в выпусках новостей?

Повсеместно внедрить статический анализ кода на этапе разработки. При помощи созданного в компании (или арендованного как сервис) отдела Application Security, построить модели угроз для каждого приложения, определить наиболее опасные проблемы, дать разработчикам полные инструкции по устранению уязвимости.

Постепенно выстроить процессы SecurityDevOps, позволяющие сделать интеграцию процессов ИБ, ИТ и разработки максимально простой и прозрачной. Определить, какие ИБ-процессы задействованы при защите приложений. Понять, на что обращать внимание при формировании технологического стека.

Реализовать управление уязвимостями и несоответствиями – к примеру, обязательное устранение уязвимостей, выявленных в новой сборке, когда команда «разбирает» уязвимости, полученные при первичном сканировании, в том числе через инструмент единого окна, где будут отображаться статусы по уязвимостям в ПО с точки зрения не только кода, но и инфраструктуры, используемой разработчиками и командой эксплуатации.

На базе предыдущих пунктов запустить цикл полноценного анализа защищенности каждого релиза (Secure SDLC – Secure Software Development Lifecycle), решающего задачу выпуска регулярных и защищенных релизов ПО, проводя постоянные проверки по мере внесения изменений.

Запустить у себя программу Bug Bounty (теперь она есть и в Казахстане), что позволит реализовать точку контакта между исследователем и компанией, получить данные о критических уязвимостях, оценить количество найденных ошибок, уровень их серьезности и вознаградить исследователей безопасности.