Продолжение статьи про комплексный подход реализации DevSecOps. В первой части были рассмотрены индустриальные вызовы, цели и задачи инструментов класса ASOC, Оркестрация и Корреляция.
DevSecOps by Swordfish Security. Часть первая
Меня зовут Юрий Сергеев, я основатель и управляющий партнер в Swordfish Security.
С 2017 наша компания активно занимается проблематикой построения процессов разработки защищенного ПО (Secure Software Development Lifecycle). За прошедшие годы нам посчастливилось реализовывать поистине уникальные проекты в области DevSecOps, где мы приобретали для себя самое ценное - опыт. Накопленная экспертиза и сформированные компетенции дали нам возможность создать продукт - AppSec.Hub, который позволяет реализовать интеграцию практик информационной безопасности в непрерывный процесс разработки (DevOps) и построить настоящий DevSecOps.
Под катом я поделюсь своим взглядом на вызовы при построении DevSecOps, расскажу о той степени автоматизации, которой удалось достичь на основе анализа и трансформации процессов разработки защищенного ПО.
Статья получилась внушительная, так что мне пришлось разбить ее на две части. Обе будут опубликованы сегодня.
Оценочный уровень доверия (ОУД4) и ГОСТ Р ИСО/МЭК 15408-3-2013. Разработчик
Вторая статья цикла, посвященного ОУД, рассказывает о проблеме с позиции разработчика прикладного ПО (или заказчика, который должен получить гарантии безопасности конечного продукта).
Давайте ненадолго абстрагируемся от ОУД. Представьте, что вы разработчик и создаете приложение для финансовых или кредитных организаций, подшефных Банку России. Или вы работаете в одной из таких организаций - банке, страховой, брокере, и являйтесь заказчиком продукта. Вы очень хотите гарантировать определенный уровень качества, и даже если не хотите - существующие SLA, нормативы регуляторов и требования контрактов заставляют прорабатывать не только функциональные требования, но и вопросы информационной безопасности. С чего же следует начать?
Развитие механизмов безопасности Android (от версии к версии)
Привет, Хабр!
Я занимаюсь безопасностью мобильных приложений и с удовольствием слежу за развитием платформ Android и iOS, которые с каждым новым релизом становятся все привлекательнее для пользователей, «обрастают» новой интересной функциональностью и вместе с тем повышается их защищенность… или нет?
Сегодня я хотел бы сделать небольшой обзор развития различных функций безопасности системы Android, как внутренних, направленных на усиление безопасности самой платформы, так и внешних, напрямую относящихся к приватности и данным пользователей. Статья не претендует на оригинальность, все материалы есть в свободном доступе, но они рассредоточены по множеству публикаций. Мне показалась интересной попытка собрать эту информацию и проследить, как эволюционировала безопасность Android от версии к версии, чему уделялось внимание в каждом релизе и как это повлияло на дальнейшее развитие. В статье я постараюсь дать ссылки на различные ресурсы, где можно подробнее почитать о терминах, технологиях и прочем. Хотелось бы всё это рассказать в текущей статье, но тогда она рискует никогда не выйти.
Надеюсь, статья понравится и будет полезна всем, кто увлекается безопасностью мобильных приложений и операционных систем.
Оценочный уровень доверия (ОУД4) и ГОСТ Р ИСО/МЭК 15408-3-2013. Введение
Привет, Хабр!
В настоящее время в ИТ индустрии крайне актуальна тема построения процесса безопасной разработки ПО (по англ. «Secure SDLC» или «Secure software development life cycle»). Некоторые организации и команды самостоятельно приходят к необходимости такого процесса в своих продуктах, свободно выбирают подходящий фреймворк, инструменты и выстраивают свой вариант безопасной разработки. Другие, подпадающие под внешние регуляции, вынуждены разбираться с конкретными, заранее выбранными регуляторами фреймворками или стандартами. Ко второму варианту относятся многочисленные финансовые организации, деятельность которых регулируется Банком России. В нормативах последнего с мая 2018 года стали фигурировать вопросы анализа уязвимостей и появилась аббревиатура ОУД 4.
Этой статьёй я хочу начать цикл, освещающий процессы безопасной разработки в контексте стандартов серии ГОСТ Р ИСО/МЭК 15408. Моя задача – последовательно, фундаментально и лаконично изложить этот фреймворк, чтобы уменьшить «порог вхождения» в предмет. Материал предназначен для разработчиков, менеджеров, методологов и других людей, которые в силу обстоятельств, вынуждены погружаться в безопасную разработку в контексте ОУД и требований Банка России.
Подробнее под катом…
CodeQL: SAST своими руками (и головой). Часть 1
Привет, Хабр!
Как вы все уже знаете, в области безопасности приложений без статических анализаторов исходного кода (SAST) совсем никуда. SAST-сканеры занимаются тем, что проверяют код приложения на различные типы программных ошибок, которые могут скомпрометировать систему, предоставить злоумышленнику непредвиденные возможности для доступа к данным, либо для нарушения работы приложения. В основном анализ безопасности кода строится на изучении его семантической структуры, путей прохождения данных от момента пользовательского ввода до обработки. Однако есть и обычная для таких инструментов возможность поиска наиболее часто встречающихся небезопасных паттернов.
В этой статье я расскажу о CodeQL от GitHub Security Lab, интересном инструменте и языке для анализа исходного кода, который активно набирает популярность и выглядит весьма перспективным.
Лучшие практики при написании безопасного Dockerfile
В данной статье мы рассмотрим небезопасные варианты написания собственного Dockerfile, а также лучшие практики, включая работу с секретами и встраивание инструментов статического анализа. Тем не менее для написания безопасного Dockerfile наличия документа с лучшими практиками мало. В первую очередь требуется организовать культуру написания кода. К ней, например, относятся формализация и контроль процесса использования сторонних компонентов, организация собственных Software Bill-of-Materials (SBOM), выстраивание принципов при написании собственных базовых образов, согласованное использование безопасных функций, и так далее. В данном случае отправной точкой для организации процессов может служить модель оценки зрелости BSIMM. Однако в этой статьей пойдет речь именно о технических аспектах.
Интеграция Netsparker с AD через Keycloak
Привет, Хабр!
Как-то раз в нашей работе встретилась необходимость провести интеграцию сканера безопасности Netsparker и службы каталогов Active Directory. В этой статье я поделюсь инструкцией о том, как можно это сделать и на что стоит обратить внимание при настройке.
Забегая вперед, стоит отметить, что аналогичные шаги помогут настроить интеграцию с AD не только Netsparker, но и иных приложений, которые не имеют собственных средств взаимодействия с Active Directory.
Анонс: Ломаем приложение в Docker и строим безопасный пайплайн в Gitlab
20 ноября пройдет ежегодная конференция Archdays, где мы c Пашей Канн в рамках демонстрации покажем пример того, как может быть взломано приложение в Docker и как с нуля собрать пайлпайн с проверками безопасности на базе GitLab CI.
Взлом будет проходить в соответствии с инструкцией репозитория Pentest-In-Docker, который мы подготовили специально для Archdays. Есть также версия на русском языке, попробовать получить root на linux-хосте можно уже сейчас.
Just for fun: Сколько «живет» iOS до Jailbreak
Привет, Хабр!
Наткнулись тут в Википедии на информацию: сколько дней продержалась каждая версия iOS до Jailbreak. В итоге соорудили инфографику just for fun.
Способы и примеры внедрения утилит для проверки безопасности Docker
Привет, Хабр!
В современной реальности из-за возрастающей роли контейнеризации в процессах разработки не на последнем месте стоит вопрос обеспечения безопасности различных этапов и сущностей, связанных с контейнерами. Осуществление проверок в ручном режиме является трудоёмким занятием, поэтому было бы неплохо сделать хотя бы начальные шаги к автоматизации этого процесса.
В этой статье я поделюсь готовыми скриптами для внедрения нескольких утилит обеспечения безопасности Docker и инструкцией, как развернуть небольшой демо-стенд для проверки этого процесса. Материалами можно воспользоваться, чтобы поэкспериментировать с тем, как организовать процесс тестирования безопасности образов и инструкций Dockerfile. Понятно, что инфраструктура разработки и внедрения у всех разные, поэтому ниже я приведу несколько возможных вариантов.
Как написать правила для Checkmarx и не сойти с ума
Привет, Хабр!
В своей работе наша компания очень часто имеет дело с различными инструментами статического анализа кода (SAST). Из коробки они все работают средне. Конечно, всё зависит от проекта и используемых в нём технологий, а также, насколько хорошо эти технологии покрываются правилами анализа. На мой взгляд, одним из самых главных критериев при выборе инструмента SAST является возможность настраивать его под особенности своих приложений, а именно писать и изменять правила анализа или, как их чаще называют, Custom Queries.
Мы чаще всего используем Checkmarx - очень интересный и мощный анализатор кода. В этой статье я расскажу про свой опыт написания правил анализа для него.
От Threat Modeling до безопасности AWS: 50+ open-source инструментов для выстраивания безопасности DevOps
Привет, Хабр! Я консультант по информационной безопасности в Swordfish Security по части выстраивания безопасного DevOps для наших заказчиков. Я слежу за тем, как развивается тенденция развития компаний в сторону DevSecOps в мире, пытаюсь транслировать самые интересные практики в русскоговорящее сообщество и помогаю выстраивать этот процесс с нашей командой у заказчиков. За последние 2 года тема DevSecOps стала привлекать все больше внимания. Новые инструменты не успевают стать частью быстро растущего набора практик, из-за чего у меня появилось желание поставить некоторую контрольную точку в виде списка инструментов. Отправной точкой стал выход статьи коллег из Mail.ru, где отдельно был выделен раздел по безопасности Kubernetes. Я решил расширить этот список, охватив другие этапы жизненного цикла SDLC и приведя пару новых инструментов.
DevSecOps: принципы работы и сравнение SCA. Часть первая
Информация
- Дата регистрации
- Дата основания
- Численность
- 101–200 человек
- Местоположение
- Россия
- Представитель
- SwordfishTeam