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

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

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

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

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

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

Всем привет! Меня зовут Тимур Гильмуллин, я руководитель направления по построению процессов безопасной разработки в компании Positive Technologies. Раньше я работал в DevOps-отделе, где инженеры занимаются автоматизацией различных процессов и помогают программистам и тестировщикам. В числе прочего мы проводили работы, связанные с внедрением инструментов безопасной разработки в CI/CD-конвейер. В этой статье я рассмотрю концепцию безопасной разработки DevSecOps (или SecDevOps) в целом: разберемся, что это за концепция, что она дает бизнесу, разработчикам, инженерам DevOps и безопасникам, какие инструменты можно при этом использовать и насколько трудоемко их внедрение.

Привет, Хабр!
Приглашаем начать “давайте после майских” с митапа :)  Ждем вас 12 мая в 18:00 на новый CROC&TALK – в этот раз будем обсуждать DevSecOps. 

Поговорим о том, как запустить процесс безопасной разработки, не выстрелить себе в колено, а спецам по информационной безопасности и разработке заговорить на одном языке. Будет 2 доклада по практическим кейсам и дискуссия. Подробности – под катом или сразу на странице мероприятия.

Важно: митап будет офлайн+онлайн, если вы в Москве, ждем в нашем офисе на пиццу и приятное общение :) 

Говорят, обещанного три года ждут, но не прошло и двух, с появления первой части перевода, как я решил не ждать продолжения и перевести OWASP Application Security Verification Standard самостоятельно. В первой части помимо раздела об архитектуре было подробное введение, дающее представление о стандарте и его назначении. Всем, кто его читал, и тем, кто знаком с ASVS в оригинале, сразу даю ссылку на итоговый pdf и другие форматы, — возможно, вы откроете для себя что-то новое. Всем остальным предлагаю несколько слайдов в качестве быстрого погружения.

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

Меня зовут Света Газизова, я ведущий аудитор компании Swordfish Security. Поговорим сегодня о безопасной разработке, вернее, об инструментах, которые могут сделать ее проще (или нет).

Никому не хочется быть на прицеле у хакеров. Все боятся, что данные клиентов утекут в сеть. И уж тем более никто не желает видеть по ночам кошмары про DDoS-атаки. Инструменты безопасности (лекарства от всех этих страхов) вроде бы и есть, но ими сложно управлять. А кроме этого, нужно постоянно следить за разработкой. Неплохим выходом из этой мрачной реальности может стать фреймворк безопасной разработки. Главное — уметь его готовить. На сегодняшний день таких фреймворков существует несколько, самые яркие — Microsoft SDL, OWASPSAMM, OpenSAMM, BSIMM. О последнем как раз пойдёт речь в этой статье.

Содержание:

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

В крупных организациях соотношение разработчиков к безопасникам, именно к Application Security, катастрофическое — 100:1. При таком раскладе трудно ожидать от малочисленной команды AppSec-специалистов, что она покроет проверками весь код, который создают разработчики, выловит все уязвимости и обеспечит программным продуктам надежную защиту от существующих киберугроз. Сегодня поговорим о безопасности с Андреем Ивановым, директором по развитию бизнеса компании Swordfish Security, которая занимается построением процессов разработки безопасного ПО.

Open Web Application Security Project (OWASP) — одна из самых известных организаций, целью которой является улучшение защищённости приложений. Большинство специалистов в области информационной безопасности знакомы с OWASP Top Ten. У OWASP есть множество других проектов для различных этапов жизненного цикла разработки программного обеспечения (SDLC).

В предыдущей статье на Хабр я рассказывал о стандарте OWASP ASVS, в котором перечислены требования к безопасности web-приложений. А как убедиться в том, что эти требования выполняются? Ответ на этот вопрос даёт Web Security Testing Guide (WSTG) — Руководство по тестированию безопасности web-приложений, перевод которого я хотел бы представить вашему вниманию.

Всем привет! Меня зовут Николай Шуляев, и это моя вторая статья на Хабре (первая – тут). В этот раз я хотел бы поднять достаточно важный для меня и отчасти провокационный вопрос: Так ли нужен WAF?