А почему в голосовалке нет пункта о наличии и количестве участников программы Bug Bounty, выплаченных вознаграждениях? Соотношении обнаруженных и закрытых уязвимостей, среднем времени их устранения?..
В направлении безопасной разработки - несомненно. Но, допустим, из тестировщика может получиться пентестер, из админа - аналитик SOC, из дата-сайентиста - спец по антифроду и т.д. Карьерных треков не так мало. Хороший обзор - https://habr.com/ru/companies/pt/articles/800865/.
Интересно было бы узнать про опыт применения DSO GL - какими инструментами из рекомендуемых вы пользуетесь (моделирование угроз, SCA, SBOM, SAST, DAST, IAST, RASP, CNAPP, etc.)?
Добр пожаловать в Software-defined Vehicle! В связи с несоответствием регламенту UN ECE R155/156, самая продаваемая модель Porsche - внедорожник Macan, планировавшийся к выходу на европейский рынок в марте, не будет доступен для продажи. Производитель говорит, что «обновление прошивки двигателя внутреннего сгорания в соответствии с регламентом, который вступает в силу с 1 июля 2024 года, было слишком дорогостоящим». "Внедрение директивы требует не только корректировок в технической реализации, например, в блоках управления, но и, по сути, изменения процессов на этапе разработки. Например, должен быть сертифицирован процесс безопасной разработки системы управления".
И ещё про сближение ИТ и ИБ. Чтобы при приёмке снять вопросы «Почему и откуда взялось это требование?» (любое, не только ИБ), помогает матрица трассировки требований (RTM). В неё на этапе проектирования внести все важные для продукта аспекты качества из ISO 25010, применимые угрозы безопасности и нормативно-правовые требования. По каждому пункту указать, почему появилось это требование, сценарии тестирования и критерии приёмки. RTM работает в обе стороны: от требований к тестовым примерам обеспечивается полное покрытие тестами (TDD), а в обратном направлении мы убеждаемся, что в продукте не появились недокументированные возможности и его скоуп не «поплыл». Если при приёмке какой-нибудь тест не прошел, регистрируется дефект. При отсутствии критичных дефектов релиз едет в Прод…
ЗдОрово, что вспомнили незаслуженно игнорируемый продукт-менеджерами ISO 25010! - эта модель лучше всего «мирит» ИТ и ИБ, справедливо относя безопасность к аспектам качества продукта. Взрослые (в смысле SAMM/DSOMM) компании стараются измерять метрики по всем характеристикам качества непрерывно в рамках DevSecOps. «Компартментализация» входит в концепцию Zero Trust в виде микросегментации. Несмотря на проходящий хайп, в ZTA заложены правильные ингредиенты.
Также есть CBOM - Cryptographic Bill of Materials, чтобы выявлять используемые криптографические примитивы и оперативно реагировать в случае доказательства их уязвимости.
DSOGL - это рекомендации и лучшие практики для формулирования стратегии DevSecOps. «Уделяя особое внимание обучению и осведомлённости, эта инициатива способствует формированию культуры осознанного отношения к безопасности в командах. Она побуждает к обучению, сотрудничеству и эффективному применению мер защиты, демонстрируя целостный подход к DevSecOps».
DSOMM - модель непрывного совершенствования методов безопасности DevOps на основе SAMM. «Оценив текущий уровень зрелости, команды могут определить конкретные области для улучшения. Модель помогает планировать и внедрять постепенные улучшения, обеспечивая постепенный рост возможностей. Она основана на поэтапном подходе, позволяющем оценивать прогресс, адаптироваться к возникающим угрозам и со временем совершенствовать методы обеспечения защиты. Такой постепенный подход позволяет создать систему DevSecOps, соответствующую меняющимся потребностям и задачам безопасности бизнеса». На основе этой модели также адаптирована идея с награждением Security Champions поясами разных цветов за достижения.
Как же вы забыли про HackTheBox? Это то что позволяет начать почти с нуля и соединить блестяще изложенную теорию с хорошей практикой с элементами геймификации. Про Portswigger ни слова… Также мне нравятся Cybrary и PluralSight.
Белые шляпы, конечно, могут и подождать. А что делать с черными? У них ипотека, им ждать некогда.
Конечно! Поскольку не бывает ПО без уязвимостей, покупателей волнует как у разработчика поставлен процесс управления уязвимостями. Если статистики по обнаруженным/исправленным нет, то либо их никто не тестирует, либо не исправляет, либо исправляет, но так долго, что стыдно это публиковать. Наиболее зрелые компании не ограничиваются внутренним тестированием, т.к. его охват ограничен ресурсами, и запускают публичные программы. Посмотрите, например, результаты https://communityblog.fedoraproject.org/exploring-our-bugs-part-1-the-basics/, https://www.wired.com/story/hack-the-pentagon-bug-bounty-results/. Вот наши площадки https://codeby.school/blog/informacionnaya-bezopasnost/ohota-na-bagi-spisok-ploschadok-dlya-bug-bounty.
А почему в голосовалке нет пункта о наличии и количестве участников программы Bug Bounty, выплаченных вознаграждениях? Соотношении обнаруженных и закрытых уязвимостей, среднем времени их устранения?..
Если уж так хотелось избавиться именно от гугл, то в DuckDuckGo вместо !g запрос лучше начать с !s, который ищет там же, но через Startpage…
В направлении безопасной разработки - несомненно. Но, допустим, из тестировщика может получиться пентестер, из админа - аналитик SOC, из дата-сайентиста - спец по антифроду и т.д. Карьерных треков не так мало. Хороший обзор - https://habr.com/ru/companies/pt/articles/800865/.
«Для этого надо всего лишь» почаще задавать себе 4 вопроса, которые придумал гуру моделирования угроз Адам Шостак:
Что мы строим?
Что может пойти не так?
Что мы собираемся с этим делать?
Достаточно ли мы сделали, чтобы устранить проблему?
См. https://habr.com/ru/companies/vk/articles/504062/
В таблице с плагинами не хватает информации о назначении плагинов. Или это всё линтеры? Есть для IAST, SBOM?..
Интересно было бы узнать про опыт применения DSO GL - какими инструментами из рекомендуемых вы пользуетесь (моделирование угроз, SCA, SBOM, SAST, DAST, IAST, RASP, CNAPP, etc.)?
Вошли в февральский Patch Tuesday
Добр пожаловать в Software-defined Vehicle! В связи с несоответствием регламенту UN ECE R155/156, самая продаваемая модель Porsche - внедорожник Macan, планировавшийся к выходу на европейский рынок в марте, не будет доступен для продажи. Производитель говорит, что «обновление прошивки двигателя внутреннего сгорания в соответствии с регламентом, который вступает в силу с 1 июля 2024 года, было слишком дорогостоящим». "Внедрение директивы требует не только корректировок в технической реализации, например, в блоках управления, но и, по сути, изменения процессов на этапе разработки. Например, должен быть сертифицирован процесс безопасной разработки системы управления".
И ещё про сближение ИТ и ИБ. Чтобы при приёмке снять вопросы «Почему и откуда взялось это требование?» (любое, не только ИБ), помогает матрица трассировки требований (RTM). В неё на этапе проектирования внести все важные для продукта аспекты качества из ISO 25010, применимые угрозы безопасности и нормативно-правовые требования. По каждому пункту указать, почему появилось это требование, сценарии тестирования и критерии приёмки. RTM работает в обе стороны: от требований к тестовым примерам обеспечивается полное покрытие тестами (TDD), а в обратном направлении мы убеждаемся, что в продукте не появились недокументированные возможности и его скоуп не «поплыл». Если при приёмке какой-нибудь тест не прошел, регистрируется дефект. При отсутствии критичных дефектов релиз едет в Прод…
ЗдОрово, что вспомнили незаслуженно игнорируемый продукт-менеджерами ISO 25010! - эта модель лучше всего «мирит» ИТ и ИБ, справедливо относя безопасность к аспектам качества продукта. Взрослые (в смысле SAMM/DSOMM) компании стараются измерять метрики по всем характеристикам качества непрерывно в рамках DevSecOps. «Компартментализация» входит в концепцию Zero Trust в виде микросегментации. Несмотря на проходящий хайп, в ZTA заложены правильные ингредиенты.
Почему же, есть HBOM.
А из каких слов состоит сокращение ЦАП? Есть ссылочки на эти литературы?
Спасибо, полезный материал, надо изучить. Из собственных находок по теме:
Примеры угроз из OWASP Top 10 API Security ‘23 в коде GraphQL и меры защиты от них.
Памятка OWASP по GraphQL.
Также есть CBOM - Cryptographic Bill of Materials, чтобы выявлять используемые криптографические примитивы и оперативно реагировать в случае доказательства их уязвимости.
Как уже писал выше, судя по DAC=ЦАП - это похоже на машинный перевод, но если так, почему нет ссылки на первоисточник?..
ЦАП, конечно, тоже DAC. Казалось бы, причем тут цифро-аналоговое преобразование…
На эту тему у OWASP есть пара проектов:
DSOGL - это рекомендации и лучшие практики для формулирования стратегии DevSecOps. «Уделяя особое внимание обучению и осведомлённости, эта инициатива способствует формированию культуры осознанного отношения к безопасности в командах. Она побуждает к обучению, сотрудничеству и эффективному применению мер защиты, демонстрируя целостный подход к DevSecOps».
DSOMM - модель непрывного совершенствования методов безопасности DevOps на основе SAMM. «Оценив текущий уровень зрелости, команды могут определить конкретные области для улучшения. Модель помогает планировать и внедрять постепенные улучшения, обеспечивая постепенный рост возможностей. Она основана на поэтапном подходе, позволяющем оценивать прогресс, адаптироваться к возникающим угрозам и со временем совершенствовать методы обеспечения защиты. Такой постепенный подход позволяет создать систему DevSecOps, соответствующую меняющимся потребностям и задачам безопасности бизнеса». На основе этой модели также адаптирована идея с награждением Security Champions поясами разных цветов за достижения.
Как же вы забыли про HackTheBox? Это то что позволяет начать почти с нуля и соединить блестяще изложенную теорию с хорошей практикой с элементами геймификации. Про Portswigger ни слова… Также мне нравятся Cybrary и PluralSight.