Безопасная разработка: как сократить затраты на киберзащиту до релиза продукта

Всем привет, меня зовут Александр Герасимов, я директор по ИБ в Awillix — разработчика решений в области кибербезопасности. Часто мое общение с продуктовыми компаниями начинается со слов — «Нас взломали». А это означает — слив коммерческой тайны или клиентских данных, миллионные потери, удар по репутации и иногда даже шантаж. Тогда я рассказываю про инструменты защиты и объясняю, как оценить код с точки зрения безопасности, выстроить «безопасный» процесс разработки. А сегодня кратко и по существу расскажу все эти базовые принципы в тексте.

Содержание:

— Что такое безопасная разработка и зачем она нужна

— Внедрение SSDLC, мифы и реальность

— Подводя итоги: пять шагов к безопасному коду

— Несколько важных замечаний

Разработку IT-продукта принято описывать в терминах жизненного цикла (SDLС – Software development lifecycle), который включает в себя несколько этапов:

Поскольку современные IT-продукты постоянно развиваются, SDLС повторяется многократно, а вслед за этапом тестирования в него добавляется пункт интеграции нового кода в уже существующие production-системы.

Если бы продукт разрабатывался только для использования внутри компании, можно было бы этим и ограничиться — доступа к ПО извне нет, снаружи о нем никто не знает, а внутри коллектива вариант «внутреннего злоумышленника» даже не рассматривается. Но в реальности такая постановка вопроса звучит наивно.

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

Вывод очевиден — в процессе разработки ПО нужно оценивать возможные уязвимости и предусматривать меры, которые их нейтрализуют. Другими словами — обеспечить безопасность еще перед релизом. Если ваш продукт предназначен для внешнего мира — появляется гораздо больше желающих получить доступ к критичной информации, персональным данным клиентов или возможности влиять на работу сервиса.

Secure SDLC — набор процедур безопасной разработки ПО, позволяющий обнаруживать и устранять уязвимости на ранней стадии, до публикации релиза продукта. Любой бизнес, предлагающий свое ПО внешнему пользователю, сталкивается с необходимостью внедрения SSDLC.

Первое, с чем очень важно разобраться: качественный код и безопасный код — далеко не одно и то же. Давайте рассмотрим конкретный пример.

У вас есть сервис, позволяющий клиенту привязать карту накопительного типа. Вы описываете разработчику задачу: после авторизации в личном кабинете, пользователю предлагается заполнить поля «Номер карты» и «CVV». Если введенные данные верны — карта привязывается к пользователю.

Разработчик, получив задачу, реализует нужную форму и запрос к базе данных, в котором проверяется соответствие номера карты и ее CVV. Программный код качественный, все тесты пройдены, ошибок нет. Обновление выкатывается в production, и в этот момент выясняется, что количество попыток ввода данных было неограниченно. В результате — злоумышленник, завладев номером карты, может подобрать CVV простым перебором вариантов. Программный код в нашем примере оказался небезопасным.

Возможный вариант решения проблемы из примера выше — указать в требованиях безопасности приложения: «После каждой попытки ввода необходимо включить блокировку следующей попытки на 30 сек и внедрить CAPTCHA-тесты для блокировки множественных запросов».

Вроде бы очевидное решение, которое легко реализовать. Но кто должен это решение сформулировать, а главное — на основании чего? И тут мы подходим к важному тезису:

Качество кода — определяется уровнем квалификации разработчиков. А его безопасность — в первую очередь зависит от анализа модели угроз.

Определение модели угроз и способов их нейтрализации — требует отдельных компетенций, которыми обладают эксперты по информационной безопасности.

С необходимостью внедрения SSDLC сталкивается практически каждый бизнес, которому не безразличен собственный IT-продукт. При этом — нередко он сталкивается со множеством мифов. Давайте рассмотрим основные из них.

Хорошо, когда о возможных проблемах с безопасностью начинают задумываться на этапе обсуждения первоначальной идеи. Но как быть, если продукт уже существует и процессы разработки отлажены?

Многими внедрение SSDLC воспринимается как единый монолитный процесс, который требует остановки всего остального производства на неопределенный срок.

На самом деле, внедрение SSDLC происходит поэтапно, и для большинства бизнесов, у которых уже налажены текущие процессы — не требует их остановки. Например, можно начать с выявления моделей угроз и внедрения простых инструментов — статических анализаторов.

Статистические анализаторы кода помогут выявить небезопасное хранение секретов, проверят на уязвимости из списка OWASP Top-10, укажут на известные угрозы.

В самом «безобидном» варианте — вам больше не придется беспокоиться о том, что разработчик сохранил в коде сервиса какие-либо секреты, например, ключи доступа, пароли и прочее. В нашей практике был случай, когда к нам обратился стартап-криптообменник, потерявший все средства с одного из счетов, после того, как злоумышленники проэксплуатировали SQL-инъекцию, не замеченную в коде. Несколько сотен тысяч долларов можно было бы сохранить, просто настроив автоматическую проверку уязвимостей с помощью статистического анализа кода.

Помимо анализа кода, написанного разработчиками проекта, необходимо отслеживать внешние зависимости — каждая сторонняя библиотека доступна злоумышленникам. Они пристально изучают их, пытаясь найти уязвимости. Если это удается — библиотека становится дырой в безопасности любого приложения, в котором она использована. Создатели библиотек, в свою очередь, отслеживают активность хакеров и выпускают обновления, которые нейтрализуют обнаруженные угрозы. Подключение сервисов, которые отслеживают релизы библиотек, позволяет своевременно обновлять зависимости приложения, уменьшая тем самым число уязвимостей. Например, нашумевшая уязвимость в библиотеке журналирования Java-программ Log4j в один день стала проблемой для миллиона компаний, в том числе Apple, Microsoft и прочих.

Аналогичным образом в процесс разработки включается мониторинг, проверки логов, аудит контейнеров, если эта технология используется на проекте и так далее.

Разумеется, любые действия имеют свою цену. Но, во-первых, затраты на устранение уязвимостей на этапе проектирования обходятся гораздо дешевле, чем после выпуска продукта на рынок. А во-вторых — объемы вложений, необходимых для внедрения SSDLC напрямую зависят от потребностей бизнеса.

Если речь идет о финтех сервисе или банковском приложении — можно считать, что оно находится «в красной зоне», в которой любые вложения окупаются надежностью защиты денежных средств клиентов и самого бизнеса. В таком случае — необходимо внедрять все доступные методики обеспечения безопасности, не оглядываясь на их стоимость, поскольку цена потенциального взлома окажется на порядок выше. Если же речь идет о сервисе, например, доставки цветов без эквайринга — можно ограничиться анализом кода на уязвимости перед релизом.

Масштаб внедрения SSDLC определяется потребностями бизнеса, а его стоимость всегда существенно ниже затрат на исправление уязвимостей «постфактум» или компенсации потерь при взломе.

Если мне на самом деле уже удалось убедить вас в том, что внедрение SSDLC это не магия, а хорошо прописанный регламент, велика вероятность «свалиться» в другую крайность. Раз уж методика известна, шаги прописаны, а на рынке полно бесплатных решений с открытым кодом — зачем нанимать специалистов со стороны? Open source + здравый смысл = решение всех проблем безопасности inhouse «под ключ»!

С одной стороны — даже компании, которые, как наша, специализируются на пентестах и анализе защищенности — используют open source решения, и это на самом деле, позволяет существенно повысить безопасность разработки. С другой — нет никакого сомнения, что внутренние разработчики в состоянии самостоятельно настроить такие решения. Так почему же мы не рекомендуем своим клиентам так поступать?

Причин две. Первая — техническая. Одним из минусов open source решений является большое число ложно-позитивных (false positive) результатов — ситуаций, когда сканер предполагает, что в коде ошибка, а на самом деле ее нет. Каждый такой случай требует времени на то, чтобы разобраться. А значит, inhouse-разработчики будут отвлекаться от написания нового кода. И времени на то, чтобы найти нужную информацию и принять обоснованное решение — они потратят больше, чем специалист, изначально погруженный в проблематику защиты информации. А значит — и деньги компании будут расходоваться неэффективно.

Причина вторая и гораздо более важная — в психологии и целеполагании. Разработчик думает о том, как реализовать бизнес-логику, как добиться того, чтобы она правильно работала. Специалист по безопасности мыслит от обратного — он изначально ищет пути «неправильного» использования бизнес-логики, способы обойти заложенные в ней ограничения. И зачастую находит варианты, которые просто не пришли в голову разработчику. Причем ни один сканер кода не выявит уязвимости, которая базируется на использовании бизнес-логики непредусмотренным способом.

И вновь пример. Перед разработчиком ставится задача — реализовать в административной части приложения функцию добавления пользователей. Для этого он делает интерфейс API - /api/v2/admin/user, однако не задумывается о разграничении доступа. Любой пользователь, знающий путь до данного интерфейса, сможет добавить нового пользователя с ролью администратора. Нужны навыки, опыт и мышление специалиста по безопасности — он способен заметить такие вещи при ручном тестировании.

Выходит, что одним только open source не обойтись. Нужна экспертиза в области безопасности. А стоит ли нанимать специалистов в штат или привлечь outsource-команду — зависит от размеров бизнеса, текущего проекта и задач.

Open source решения не являются альтернативой или заменой специалистов по информационной безопасности, это один из элементов, из которых строится SSDLC.

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

Но сама идея привлечения профессионалов в области информационной безопасности — абсолютно правильная. И в большинстве случаев вариант обращения к профильному подрядчику окажется экономически выгоднее выращивания такого специалиста внутри компании или найма.

Итак, у вас есть IT-продукт. Первым делом отметим, что чем раньше вы задумаетесь об SSDLC, тем меньше будет объем кода, который потребует переработки. Но даже если ваш продукт уже вышел в релиз — его можно сделать безопасным.

Классический вариант — специалисты по безопасности сопровождают проект на всех этапах внедрения SSDLC, участвуют в разработке архитектуры приложения, занимаются обучением разработчиков правилам написания безопасного кода и его тестирования. Упрощенный вариант — «безопасники» получают уже готовый код, тестируют его и возвращают с анализом уязвимостей, рекомендациями и пошаговыми инструкциями, как все исправить.

Взаимодействие команды разработки и команды безопасности начинается с пре-аудита: интервью разработчиков, девопсов, администраторов сервиса и специалистов со стороны бизнеса. Необходимо понять, как работает приложение, кто им пользуется, какие в нем существуют роли и типовые сценарии.

На это может уйти несколько дней, но в конечном счете становится понятна возможная мотивация злоумышленников, модель внутренних и внешних угроз, какие данные для данного приложения критичны.

Для каждого процесса в приложении перебираются возможные варианты векторов атак. Например, если в приложении есть авторизация по номеру телефона, специалист по безопасности фиксирует: «Существуют угрозы, связанные с авторизацией по номеру телефона: нет ограничения времени жизни смс-кода; есть возможность множественного ввода смс-кода; есть возможность перебора телефонных номеров и так далее».

Все это описывается в виде соответствующих политик, которые разработчики учитывают при написании кода и реализуют необходимые механизмы защиты.

Для всего нового кода настраиваются автоматические проверки, в случае выявления недостатков — специалисты по безопасности верифицируют каждую в ручном режиме.

Если в коде обнаружена уязвимость — обязательно нужно подтвердить ее наличие в работающем коде. Для этого приложение полностью собирается и публикуется в тестовом сегменте, где подвергается динамическому тестированию.

Список обнаруженных уязвимостей с рекомендациями по их устранению возвращается к разработчикам, они вносят необходимые правки в код и цикл повторяется с третьего шага до полного устранения угроз.

Обеспечение информационной безопасности — не разовое действие, а непрерывный процесс. Невозможно защититься от всего и навсегда. Можно провести аудит, найти и нейтрализовать все известные угрозы, а через неделю разработчики какой-то из библиотек, использованных в вашем коде, объявят о нахождении очередной критической уязвимости и выпустят патч.

Чтобы ваш продукт не представлял угрозы для ваших клиентов:

Делать это самостоятельно, за счет внутренних ресурсов или обратиться к внешним специалистам — решайте сами. Если остались вопросы, их можно задать в комментариях или напрямую мне в телеграмм-чат https://t.me/justsecuritychat

#иб #pentest #vulnerabilities #defensive #security #SSDLC