{"id":10642,"title":"\u0411\u0438\u0437\u043d\u0435\u0441 \u043c\u043e\u0436\u043d\u043e \u0437\u0430\u0449\u0438\u0442\u0438\u0442\u044c \u043e\u0442 \u043a\u0438\u0431\u0435\u0440\u0430\u0442\u0430\u043a \u0438 \u0432\u0438\u0440\u0443\u0441\u043e\u0432 \u043d\u0430 \u0443\u0440\u043e\u0432\u043d\u0435 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0440\u0430","url":"\/redirect?component=advertising&id=10642&url=https:\/\/vc.ru\/promo\/305439-reshenie-dlya-biznesa-zashchitit-rabochie-kompyutery-i-tratit-menshe-na-tehpodderzhku&placeBit=1&hash=92cac90aee476dcf6c798d57554c147c48c9992484e9b9517cc9679e918eca49","isPaidAndBannersEnabled":false}

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

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

Содержание:

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

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

  • Миф первый: это долго или вообще невозможно встроить в уже отлаженный процесс разработки.
  • Миф второй: это очень дорого.
  • Миф третий: Все можно сделать своими силами, используя open source решения.
  • Миф четвертый: все сделают за нас.

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

  • Шаг первый: формирование модели угроз.
  • Шаг второй: описание политик безопасности.
  • Шаг третий: сканирование кода.
  • Шаг четвертый: исследование тестовой сборки.
  • Шаг пятый: устранение выявленных уязвимостей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Миф первый: это долго или вообще невозможно встроить в уже отлаженный процесс разработки

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

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

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

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

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

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

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

Миф второй: это очень дорого

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

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

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

Миф третий: Все можно сделать своими силами, используя open source решения

Если мне на самом деле уже удалось убедить вас в том, что внедрение 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

0
3 комментария
Популярные
По порядку
toverovskiy

Хотите сказать, что всё будет задом наперёд?

Ответить
1
Развернуть ветку
Александр Герасимов

:)

Ответить
0
Развернуть ветку
Sergey Mironov

Вы описали стандартный процесс Waterfall. Всё это работает только на бумаге.

Ответить
0
Развернуть ветку
Читать все 3 комментария
Геозоны: разделяй и властвуй

Ильдар Бикташев, руководитель отдела картографии и алгоритмов, уже рассказывал, какие задачи стоят перед картографическими сервисами Master Delivery. Сегодня продолжаем разговор о том, как геоаналитические разработки решают маркетинговые и логистические задачи бизнеса.

Самые сильные идеи в жизни

Предприниматель Сахил Блум публикует в своем Твиттере интересные жизненные идеи и парадоксы. Представляю перевод твиттер треда «22 самых сильных идей в жизни».

Идеальный тимлид: миф или реальность?

Кто такой идеальный тимлид? Что ожидает руководство от такого сотрудника? Колонка Алексея Кирсанова, руководителя разработки «Битрикс24».

Акции роста российских эмитентов на ближайшие 5 лет

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

«Многие из вас не догадываются, что живут с обломком металла в зубах»: почему стоматологи не признаются в своих ошибках

Как реагировать на врачебные ошибки и что делать, если вы в стоматологическом кресле и врач начинает говорить о рисках.

Теряли 10-15% рекламного бюджета и однажды потратили 1 млн рублей на аудит: история ошибок в продвижении сети клиник

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

Так выглядит наш кабинет при проверке AdSensor
Jungheinrich строит автоматизированный логистический центр для Prodrive Technologies с мобильными роботами arculee AMR

• Первый проект с новым продуктом arculee AMR для Jungheinrich

Twitter приобрел миноритарный пакет акций Aleph Group — материнской компании Httpool

Twitter Inc. (TWTR) — первая из компаний Кремниевой долины, которая стала акционером глобальной рекламной группы Aleph, объединяющей компании IMS, Httpool, Wise.Blue и AdDynamo. Таким образом Twitter поддержит международную образовательную инициативу Aleph Group по усилению цифровой экосистемы в странах с развивающейся экономикой.

Я устал искать ботов где можно купить рекламу и создал Amazon для объявлений Telegram ботов

Теперь можно выставить объявление о продаже рекламы в 1 клик (и пару заполненных полей), а также сортировать и фильтровать предложения на рынке. И всё это без регистраций и смс!

Яндекс.Маркет» не доставил мой заказ и не вернул деньги. Часть 2

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

Утиные истории. Кейс о том, как мы разрабатывали стратегию для фермеров направленную на повышение спроса
null