ИИ агент от создателей Chat GPT который может заметно изменить процесс SSDLC в большинстве компаний https://openai.com/index/introducing-aardvark/
Openai
Introducing Aardvark: OpenAI’s agentic security researcher
Now in private beta: an AI agent that thinks like a security researcher and scales to meet the demands of modern software.
Вышел новый state of devops 2025 https://devopsrussia.ru/ . В этот раз с интересным разделом по ИБ.
State of DevOps Russia 2025
Результаты масштабного исследования состояния DevOps в России. Полная версия отчета!
👍1
Forwarded from OWASP RU
Русский перевод и адаптация OWASP Application Security Verification Standard
Стандарт верификации требований к безопасности приложений — это перечень требований к безопасности приложений (тестов), которыми могут пользоваться архитекторы, разработчики, тестировщики, специалисты по безопасности, разработчики инструментов и конечные пользователи для проектирования, разработки, тестирования и контроля безопасных приложений.
Пятая версия стандарта верификации требований к безопасности приложений опирается на предыдущие версии ASVS, начиная с первой, вышедшей в 2008 году, и до четвертой, в 2019 году.
После выхода версии ASVS 4.0 в 2019 году и ее незначительного обновления (v4.0.3) в 2021 году, версия 5.0 является значительным шагом вперед — она была модернизирована, чтобы учесть последние достижения в области безопасности программного обеспечения.
ASVS 5.0 стал результатом масштабного вклада руководителей проекта, членов рабочей группы и широкого сообщества OWASP, направленного на обновление и совершенствование этого важного стандарта.
Область действия ASVS
Область действия ASVS определяется его названием: Приложение (Application), Безопасность (Security), Верификация (Verification) и Стандарт (Standard). Он устанавливает, какие требования включены в стандарт, а какие — исключены из него, с глобальной целью определения основополагающих принципов безопасности, которые должны быть достигнуты. Область действия также учитывает требования к документации, которые служат основой для требований к реализации.
Не существует такого понятия, как «область действия» для злоумышленника. Поэтому требования ASVS должны оцениваться в совокупности с рекомендациями по другим аспектам жизненного цикла приложения, включая процессы CI/CD, хостинг и операционную деятельность.
Приложение
ASVS определяет «Приложение» как разрабатываемый программный продукт, в который должны быть интегрированы механизмы безопасности. ASVS не регламентирует процессы жизненного цикла разработки и не указывает на методы сборки приложения в CI/CD. Его задача — описать требуемый уровень защищённости, который должен быть достигнут в конечном продукте.
Компоненты для обработки HTTP-трафика (WAF, балансировщики нагрузки, прокси) могут считаться частью приложения в контексте безопасности, поскольку некоторые механизмы безопасности напрямую зависят от них или могут быть реализованы с их помощью. Это касается требований по кешированию, rate limiting, а также фильтрации входящих/исходящих подключений по источнику и получателю.
В свою очередь, ASVS не включает требования, не относящиеся к приложению напрямую или находящиеся за пределами его зоны ответственности. Так, например, проблемы DNS обычно относятся в ведении отдельной команды или функции.
Аналогично, хотя в зону ответственности приложения входит обработка входящих данных и генерация исходящих данных, если внешний процесс взаимодействует с приложением или его данными, это считается выходящим за рамки ASVS. Например, резервное копирование приложения или его данных обычно выполняется внешними процессами и не контролируется самим приложением или его разработчиками.
Безопасность
Каждое требование должно иметь очевидное влияние на безопасность. Отсутствие требования должно привести к снижению уровня защищённости приложения, а реализация требования должна либо уменьшить вероятность возникновения риска безопасности, либо смягчить последствия.
Все прочие аспекты, такие как функциональные характеристики, стиль кода или требования политик, выходят за рамки стандарта.
Верификация
Требование должно быть верифицируемым, а его проверка должна приводить к однозначному решению: «не выполнено» или «выполнено».
Стандарт
ASVS представляет собой набор требований безопасности, которые необходимо реализовать для соответствия стандарту. Это означает, что требования ограничиваются определением целевого показателя безопасности, которого необходимо достичь. Прочая сопутствующая информация может быть надстроена на основе ASVS или связана с ним через сопоставления.
PDF RU
Стандарт верификации требований к безопасности приложений — это перечень требований к безопасности приложений (тестов), которыми могут пользоваться архитекторы, разработчики, тестировщики, специалисты по безопасности, разработчики инструментов и конечные пользователи для проектирования, разработки, тестирования и контроля безопасных приложений.
Пятая версия стандарта верификации требований к безопасности приложений опирается на предыдущие версии ASVS, начиная с первой, вышедшей в 2008 году, и до четвертой, в 2019 году.
После выхода версии ASVS 4.0 в 2019 году и ее незначительного обновления (v4.0.3) в 2021 году, версия 5.0 является значительным шагом вперед — она была модернизирована, чтобы учесть последние достижения в области безопасности программного обеспечения.
ASVS 5.0 стал результатом масштабного вклада руководителей проекта, членов рабочей группы и широкого сообщества OWASP, направленного на обновление и совершенствование этого важного стандарта.
Область действия ASVS
Область действия ASVS определяется его названием: Приложение (Application), Безопасность (Security), Верификация (Verification) и Стандарт (Standard). Он устанавливает, какие требования включены в стандарт, а какие — исключены из него, с глобальной целью определения основополагающих принципов безопасности, которые должны быть достигнуты. Область действия также учитывает требования к документации, которые служат основой для требований к реализации.
Не существует такого понятия, как «область действия» для злоумышленника. Поэтому требования ASVS должны оцениваться в совокупности с рекомендациями по другим аспектам жизненного цикла приложения, включая процессы CI/CD, хостинг и операционную деятельность.
Приложение
ASVS определяет «Приложение» как разрабатываемый программный продукт, в который должны быть интегрированы механизмы безопасности. ASVS не регламентирует процессы жизненного цикла разработки и не указывает на методы сборки приложения в CI/CD. Его задача — описать требуемый уровень защищённости, который должен быть достигнут в конечном продукте.
Компоненты для обработки HTTP-трафика (WAF, балансировщики нагрузки, прокси) могут считаться частью приложения в контексте безопасности, поскольку некоторые механизмы безопасности напрямую зависят от них или могут быть реализованы с их помощью. Это касается требований по кешированию, rate limiting, а также фильтрации входящих/исходящих подключений по источнику и получателю.
В свою очередь, ASVS не включает требования, не относящиеся к приложению напрямую или находящиеся за пределами его зоны ответственности. Так, например, проблемы DNS обычно относятся в ведении отдельной команды или функции.
Аналогично, хотя в зону ответственности приложения входит обработка входящих данных и генерация исходящих данных, если внешний процесс взаимодействует с приложением или его данными, это считается выходящим за рамки ASVS. Например, резервное копирование приложения или его данных обычно выполняется внешними процессами и не контролируется самим приложением или его разработчиками.
Безопасность
Каждое требование должно иметь очевидное влияние на безопасность. Отсутствие требования должно привести к снижению уровня защищённости приложения, а реализация требования должна либо уменьшить вероятность возникновения риска безопасности, либо смягчить последствия.
Все прочие аспекты, такие как функциональные характеристики, стиль кода или требования политик, выходят за рамки стандарта.
Верификация
Требование должно быть верифицируемым, а его проверка должна приводить к однозначному решению: «не выполнено» или «выполнено».
Стандарт
ASVS представляет собой набор требований безопасности, которые необходимо реализовать для соответствия стандарту. Это означает, что требования ограничиваются определением целевого показателя безопасности, которого необходимо достичь. Прочая сопутствующая информация может быть надстроена на основе ASVS или связана с ним через сопоставления.
PDF RU
Forwarded from Порвали два трояна
Можно бесконечно смотреть на то, как горит огонь, течёт вода и атакующие эксплуатируют ошибки конфигурации Exchange. Но даже если положить конец этому безобразию невозможно, уменьшить его масштабы очень желательно.
Ощутимый вклад в это благое дело на днях внесли ИБ-регуляторы англоязычных стран, опубликовав пятнадцатистраничное руководство Microsoft Exchange Server Security Best Practices.
Документ разделён на два больших раздела — Prevention posture и Harden authentication and encryption.
В первом даны рекомендации по минимальному набору безопасных настроек со ссылками на ещё более подробные security baselines от CIS, DISA и Microsoft, адаптированные для конкретных версий Exchange. Также перечислены встроенные инструменты защиты и механизмы оперативного обновления, которые авторы рекомендуют активировать.
В разделе про харденинг, которому уделено две трети документа, рекомендованы более сложные настройки и изменения, значительно повышающие стойкость сервера к современным атакам:
Тем, кто продолжает пользоваться Exchange, стоит взять этот чеклист на вооружение.
#советы #Microsoft @П2Т
Please open Telegram to view this post
VIEW IN TELEGRAM
https://owasp.org/Top10/2025/0x00_2025-Introduction/
Релиз кандидат Owasp top ten web.
На первом месте остается Broken access control.
На второе место вышли с пятого security misconfiguration.
Software supply chain был объединен с vulnerable and outdated components.
На 10 месте расположилась новая категория по некорректной обработке ошибок.
Итого проект топ 2025 выглядит так:
A01:2025 - Broken Access Control
A02:2025 - Security Misconfiguration
A03:2025 - Software Supply Chain Failures
A04:2025 - Cryptographic Failures
A05:2025 - Injection
A06:2025 - Insecure Design
A07:2025 - Authentication Failures
A08:2025 - Software or Data Integrity Failures
A09:2025 - Logging & Alerting Failures
A10:2025 - Mishandling of Exceptional Conditions
Не могу не отметить, что в выборке github топ уязвимостей в этом анализе
https://habr.com/ru/articles/963774/ топ немного другой:
1. Broken acces control.
2-3 место insecure design, injection
4,5,6 Security misconfigration, Security logging and monitoring failrues, Cryptographic failrues.
7. Software and data integrity failrues
8. Identification and authentication failrues
9. server side request forgery SSRF.
Релиз кандидат Owasp top ten web.
На первом месте остается Broken access control.
На второе место вышли с пятого security misconfiguration.
Software supply chain был объединен с vulnerable and outdated components.
На 10 месте расположилась новая категория по некорректной обработке ошибок.
Итого проект топ 2025 выглядит так:
A01:2025 - Broken Access Control
A02:2025 - Security Misconfiguration
A03:2025 - Software Supply Chain Failures
A04:2025 - Cryptographic Failures
A05:2025 - Injection
A06:2025 - Insecure Design
A07:2025 - Authentication Failures
A08:2025 - Software or Data Integrity Failures
A09:2025 - Logging & Alerting Failures
A10:2025 - Mishandling of Exceptional Conditions
Не могу не отметить, что в выборке github топ уязвимостей в этом анализе
https://habr.com/ru/articles/963774/ топ немного другой:
1. Broken acces control.
2-3 место insecure design, injection
4,5,6 Security misconfigration, Security logging and monitoring failrues, Cryptographic failrues.
7. Software and data integrity failrues
8. Identification and authentication failrues
9. server side request forgery SSRF.
Хабр
Взгляд безопасника на ежегодный отчет Github Octoverse 2025
Всем привет! Сделал для вас анализ ключевых положений нового крутого отчета Github с точки зрения безопасности. Меня зовут Василий Пластунов и я люблю делать анализ тенденций которые повлияют на...
Forwarded from Порвали два трояна
Аккурат к новому циклу бюджетирования IANS подвёз исследование о тратах на ИБ, составленное по опросу почти 600 CISO из разных стран и вертикалей бизнеса. Хотя выводы делались для западных компаний, большинство наблюдений актуальны и для наших широт.
Авторы отчёта советуют CISO внимательно смотреть на нужды бизнеса, расставлять приоритеты и соразмерять аппетиты:
#CISO @П2Т
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html
Сильный голос Google за - использовать memory safe Rust для снижения расходов на поиск, устранение и компенсирующие меры для уязвимостей. Приятный плюс - уменьшение до 4 раз количество откатов новых сборок.
Сильный голос Google за - использовать memory safe Rust для снижения расходов на поиск, устранение и компенсирующие меры для уязвимостей. Приятный плюс - уменьшение до 4 раз количество откатов новых сборок.
Google Online Security Blog
Rust in Android: move fast and fix things
Posted by Jeff Vander Stoep, Android Last year, we wrote about why a memory safety strategy that focuses on vulnerability prevention in ...
https://techcommunity.microsoft.com/blog/windows-itpro-blog/native-sysmon-functionality-coming-to-windows/4468112
В следующие релизы Win 11 и Server 2025 будет добавлен Symon, полезный инструмент для расширенного сбора логов.
В следующие релизы Win 11 и Server 2025 будет добавлен Symon, полезный инструмент для расширенного сбора логов.
TECHCOMMUNITY.MICROSOFT.COM
Native Sysmon functionality coming to Windows | Microsoft Community Hub
Learn how to eliminate manual deployment and reduce operational risk with Sysmon functionality in Windows.
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1308.2pd.pdf вторая версия проекта рекомендаций быстрого внедрения треьований безопасности по фреймворку NIST CSF 2.0.
Открыта регистрация на аналитическую конференцию Код ИБ ИТОГИ в Москве
🗓 4 декабря | Начало в 9:30
📍 Palmira Business Club
Участие бесплатное по предварительной регистрации
Выглядит интересной дискуссия по итогу года от CISO лидеров рынка в РФ, секция по безопасной разработке и секция по анализу уязвимостей.
https://codeib.ru/event/kod-ib-itogi-moskva-2025-863/page/vvedenie-kod-ib-itogi-moskva-2024
🗓 4 декабря | Начало в 9:30
📍 Palmira Business Club
Участие бесплатное по предварительной регистрации
Выглядит интересной дискуссия по итогу года от CISO лидеров рынка в РФ, секция по безопасной разработке и секция по анализу уязвимостей.
https://codeib.ru/event/kod-ib-itogi-moskva-2025-863/page/vvedenie-kod-ib-itogi-moskva-2024
Интересный отчет по рынку труда в дарквебе, пригодится для учета в вашей модели нарушителя.
Основной вывод - рынок труда в Дарквебе незначительно отстаёт от общих трендов, но тренды все равно общие.
https://securelist.com/dark-web-job-market-2023-2025/118057/
Основной вывод - рынок труда в Дарквебе незначительно отстаёт от общих трендов, но тренды все равно общие.
https://securelist.com/dark-web-job-market-2023-2025/118057/
Securelist
Inside the dark web job market
This report examines how employment and recruitment function on the dark web, based on over 2,000 job-related posts collected from shadow forums between January 2023 and June 2025.