Всем привет!

Я Юрий Сергеев, основатель и генеральный партнер Swordfish Security. В нашем блоге мы рассказываем о новых трендах в индустрии DevSecOps, о трудностях, с которыми сталкиваемся, о применяемых инструментах, а также о том, к чему готовиться в будущем.

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

Привет, Хабр!

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

Поехали!

Привет, Хабр!

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

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

Мы открыты к общению!

Привет, Хабр!

Как вы уже наверняка помните, меня зовут Юрий Шабалин и я занимаюсь разработкой динамического анализатора мобильных приложений Стингрей. Сегодня мне хотелось бы затронуть тему интеграций с системами распространения (дистрибуции) мобильных приложений. В статье рассмотрим, что представляют собой такие системы, зачем они нужны и как могут использоваться для решения задач информационной безопасности. Материал будет полезен тем, кто хочет интегрировать проверки безопасности в свой процесс разработки, но не хочет менять процесс сборки. Расскажем также про инструмент, который может в этом помочь.

Поехали!

Привет, Хабр!

Я занимаюсь безопасностью мобильных приложений и с удовольствием слежу за развитием платформ Android и iOS, которые с каждым новым релизом становятся все привлекательнее для пользователей, «обрастают» новой интересной функциональностью и вместе с тем повышается их защищенность… или нет?

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

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

Вторая статья цикла, посвященного ОУД, рассказывает о проблеме с позиции разработчика прикладного ПО (или заказчика, который должен получить гарантии безопасности конечного продукта).

Давайте ненадолго абстрагируемся от ОУД. Представьте, что вы разработчик и создаете приложение для финансовых или кредитных организаций, подшефных Банку России. Или вы работаете в одной из таких организаций - банке, страховой, брокере, и являйтесь заказчиком продукта. Вы очень хотите гарантировать определенный уровень качества, и даже если не хотите - существующие SLA, нормативы регуляторов и требования контрактов заставляют прорабатывать не только функциональные требования, но и вопросы информационной безопасности. С чего же следует начать?

Привет, Хабр!

В настоящее время в ИТ индустрии крайне актуальна тема построения процесса безопасной разработки ПО (по англ. «Secure SDLC» или «Secure software development life cycle»). Некоторые организации и команды самостоятельно приходят к необходимости такого процесса в своих продуктах, свободно выбирают подходящий фреймворк, инструменты и выстраивают свой вариант безопасной разработки. Другие, подпадающие под внешние регуляции, вынуждены разбираться с конкретными, заранее выбранными регуляторами фреймворками или стандартами. Ко второму варианту относятся многочисленные финансовые организации, деятельность которых регулируется Банком России. В нормативах последнего с мая 2018 года стали фигурировать вопросы анализа уязвимостей и появилась аббревиатура ОУД 4.

Этой статьёй я хочу начать цикл, освещающий процессы безопасной разработки в контексте стандартов серии ГОСТ Р ИСО/МЭК 15408. Моя задача – последовательно, фундаментально и лаконично изложить этот фреймворк, чтобы уменьшить «порог вхождения» в предмет. Материал предназначен для разработчиков, менеджеров, методологов и других людей, которые в силу обстоятельств, вынуждены погружаться в безопасную разработку в контексте ОУД и требований Банка России.

Подробнее под катом…

Привет, Хабр!

Как вы все уже знаете, в области безопасности приложений без статических анализаторов исходного кода (SAST) совсем никуда. SAST-сканеры занимаются тем, что проверяют код приложения на различные типы программных ошибок, которые могут скомпрометировать систему, предоставить злоумышленнику непредвиденные возможности для доступа к данным, либо для нарушения работы приложения. В основном анализ безопасности кода строится на изучении его семантической структуры, путей прохождения данных от момента пользовательского ввода до обработки. Однако есть и обычная для таких инструментов возможность поиска наиболее часто встречающихся небезопасных паттернов.

В этой статье я расскажу о CodeQL от GitHub Security Lab, интересном инструменте и языке для анализа исходного кода, который активно набирает популярность и выглядит весьма перспективным.

В данной статье мы рассмотрим небезопасные варианты написания собственного Dockerfile, а также лучшие практики, включая работу с секретами и встраивание инструментов статического анализа. Тем не менее для написания безопасного Dockerfile наличия документа с лучшими практиками мало. В первую очередь требуется организовать культуру написания кода. К ней, например, относятся формализация и контроль процесса использования сторонних компонентов, организация собственных Software Bill-of-Materials (SBOM), выстраивание принципов при написании собственных базовых образов, согласованное использование безопасных функций, и так далее. В данном случае отправной точкой для организации процессов может служить модель оценки зрелости BSIMM. Однако в этой статьей пойдет речь именно о технических аспектах.

Привет, Хабр!

Как-то раз в нашей работе встретилась необходимость провести интеграцию сканера безопасности Netsparker и службы каталогов Active Directory. В этой статье я поделюсь инструкцией о том, как можно это сделать и на что стоит обратить внимание при настройке.

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

20 ноября пройдет ежегодная конференция Archdays, где мы c Пашей Канн в рамках демонстрации покажем пример того, как может быть взломано приложение в Docker и как с нуля собрать пайлпайн с проверками безопасности на базе GitLab CI.

Взлом будет проходить в соответствии с инструкцией репозитория Pentest-In-Docker, который мы подготовили специально для Archdays. Есть также версия на русском языке, попробовать получить root на linux-хосте можно уже сейчас.

Привет, Хабр!

Наткнулись тут в Википедии на информацию: сколько дней продержалась каждая версия iOS до Jailbreak. В итоге соорудили инфографику just for fun.

Привет, Хабр! Я консультант по информационной безопасности в Swordfish Security по части выстраивания безопасного DevOps для наших заказчиков. Я слежу за тем, как развивается тенденция развития компаний в сторону DevSecOps в мире, пытаюсь транслировать самые интересные практики в русскоговорящее сообщество и помогаю выстраивать этот процесс с нашей командой у заказчиков. За последние 2 года тема DevSecOps стала привлекать все больше внимания. Новые инструменты не успевают стать частью быстро растущего набора практик, из-за чего у меня появилось желание поставить некоторую контрольную точку в виде списка инструментов. Отправной точкой стал выход статьи коллег из Mail.ru, где отдельно был выделен раздел по безопасности Kubernetes. Я решил расширить этот список, охватив другие этапы жизненного цикла SDLC и приведя пару новых инструментов.

Привет, Хабр!

В своей работе наша компания очень часто имеет дело с различными инструментами статического анализа кода (SAST). Из коробки они все работают средне. Конечно, всё зависит от проекта и используемых в нём технологий, а также, насколько хорошо эти технологии покрываются правилами анализа. На мой взгляд, одним из самых главных критериев при выборе инструмента SAST является возможность настраивать его под особенности своих приложений, а именно писать и изменять правила анализа или, как их чаще называют, Custom Queries.

Мы чаще всего используем Checkmarx - очень интересный и мощный анализатор кода. В этой статье я расскажу про свой опыт написания правил анализа для него.