Совсем скоро ноябрь, а значит, наступает время подвести итоги работы Positive Technologies за третий квартал и девять месяцев. Конечно, самый горячий период для нашего бизнеса еще впереди: основной финансовый результат формируется в четвертом квартале. Но нам уже есть что вам рассказать.

Раскрытие финансовой отчетности — 10 ноября

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

▶️ Публикация в 14:00

Онлайн-эфир — 11 ноября

Для широкой аудитории мы проведем эфир с Тимофеем Мартыновым, основателем платформы «Смартлаб». Наши топы прокомментируют результаты, обсудят бизнес и перспективы, ответят на вопросы зрителей.

▶️ Начало в 17:00
▶️ Ссылки на трансляцию будут ближе к дате

Задавайте свои вопросы уже сейчас

Оставляйте их в комментариях под этим постом. Автору самого интересного вопроса подарим музыкальную колонку. Имя победителя назовем в конце эфира, поэтому смотрите до конца 😉

Остаемся на связи!

#POSI

Главной причиной дефицита эксперты называют разрыв между образовательными программами и реальными задачами бизнеса — выпускники вузов часто не готовы работать с современной инфраструктурой и расследовать инциденты.

«ИТ и ИБ — это такие сферы, где образование почти никогда не может успеть за потребностями бизнеса. Это не хорошо и не плохо, это данность и особенность индустрии. Поэтому самое лучшее, что можно сделать за время учёбы, — это получить базу, разобраться в том, как вообще устроена сфера информационных технологий. Это огромный задел на будущее, где конкретные программы и инструменты приходят и уходят, а техническая грамотность остаётся и позволяет быть востребованным на рынке», — отмечает руководитель группы защиты инфраструктурных ИТ-решений компании «Газинформсервис» Сергей Полунин.

Одним из ответов на кадровый вызов становятся практико-ориентированные инициативы. Например, в рамках проекта Security Skills «Газинформсервис» проводит для студентов встречи с экспертами, где они знакомятся с практическими задачами — от расследования атак на «Киберарене» до применения машинного обучения в ИБ. Студенческий день форума GISDAYS 2026 — GIS STUDENT DAY, собравший более 2 тыс. студентов в Санкт-Петербурге 1 октября, также стал площадкой, где бизнес и вузы пытаются сократить этот разрыв.

Подробный обзор GIS STUDENT DAY 2026 «Газинформсервис» опубликовал на Хабре. В нём собраны главные мысли спикеров, итоги киберсоревнований и «Биржи киберстартапов», а также практические советы для начинающих специалистов по информационной безопасности.

Напомним, форум GISDAYS 2026 прошёл с 30 сентября по 2 октября в Санкт-Петербурге и Москве: 250 тыс. участников онлайн и более 3 тыс. офлайн. Студенческий день в Санкт-Петербурге 1 октября собрал более 2 тыс. студентов. На площадке работали ярмарка вакансий с собеседованиями на месте, конкурс-акселератор «Биржа киберстартапов» и CTF-турнир по криптографии, реверс-инжинирингу, форензике и веб-безопасности — в нём участвовали около 900 человек.

Следующий форум GISDAYS станет юбилейным и пройдёт 5–7 октября 2027 года.

*Global Information Security Days (GISDAYS) — дни глобальной информационной безопасности

,"offset":69,"length":277},{"_":"messageEntityBold","offset":1593,"length":33},{"_":"messageEntityCustomEmoji","offset":1853,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1853,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":1888,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1888,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":1932,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1932,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":1975,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1975,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":2019,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":2019,"length":2,"unicode":"1f310"},{"_":"messageEntityBold","offset":2465,"length":43}],"shape":"<strong >SIEM: от корреляции до расследования</>\n\nПредставим условную ситуацию:\n<blockquote data-break-after=\"\" data-break-before=\"\">1. По учетной записи сотрудника происходит 15 неудачных попыток входа в VPN.\n2. Через минуту вход удается с непривычного IP-адреса.\n3. Затем учетная запись обращается к файловому серверу, с которым обычно не работает.\n4. После этого фиксируется передача большого объема данных.</>\nКорреляционное правило может связать эти события по учетной записи и времени и сформировать сигнал для проверки.\n \nНо сама цепочка еще не доказывает атаку.\n \nСотрудник мог вернуться из командировки, несколько раз ошибиться в пароле и скачать архив для новой задачи.\n \nВозможен и другой сценарий — учетную запись использует посторонний.\n \nАналитику предстоит проверить устройство, историю активности, назначение файлов и обстоятельства доступа. SIEM помогает собрать данные для этой проверки и выделить подозрительную последовательность.\n \nВ первую очередь стоит связаться с сотрудником и верифицировать активность, подтвердить ее легитимность. Многие кейсы решаются уже на этом этапе.\n \nЕсли действия нелегитимны, необходимо изолировать потенциальную точку входа: например, выполнить сетевую изоляцию хоста и блокировку учетной записи VPN.\n \nПосле купирования необходимо определить точку проникновения и принять меры, чтобы предотвратить подобные инциденты в будущем.\n \nВ этом кейсе явно есть риск компрометации учетных данных VPN. Значит, меняем пароль, проверяем хост сотрудника на наличие ПО, которое могло перехватить учетные данные. Параллельно вычищаем следы деятельности злоумышленника и проверяем, не оставил ли он себе обходных путей.\n\n<strong >Что происходит после срабатывания</>\nSIEM может показать алерт в консоли, отправить уведомление, создать тикет или передать сигнал в SOAR для запуска сценария реагирования.\n \nОднако способ доставки — только часть задачи.\n \nДля работы с сигналом нужно понимать:\n \n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> что именно вызвало срабатывание\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> какие учетные записи и системы затронуты\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> почему сигналу присвоен такой приоритет\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> какие данные необходимо проверить дальше\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> кто отвечает за проверку и последующие действия.\n \nПриоритет зависит и от контекста.\n \nПодозрительный вход под учетной записью с широкими правами требует иного внимания, чем похожее событие в изолированной тестовой среде.\n \nАвтоматическая блокировка тоже требует заранее согласованных условий: ошибка может прервать законную работу.\n \nПоэтому связь между обнаружением и реагированием нужно проектировать вместе с владельцами инфраструктуры.\n \n<strong >SIEM не принимает решение вместо аналитика.</> Она должна дать ему достаточно данных, чтобы это решение можно было принять быстро и обоснованно."}">Представим условную ситуацию:

1. По учетной записи сотрудника происходит 15 неудачных попыток входа в VPN.
2. Через минуту вход удается с непривычного IP-адреса.
3. Затем учетная запись обращается к файловому серверу, с которым обычно не работает.
4. После этого фиксируется передача большого объема данных.

• ,"offset":69,"length":277},{"_":"messageEntityBold","offset":1593,"length":33},{"_":"messageEntityCustomEmoji","offset":1853,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1853,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":1888,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1888,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":1932,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1932,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":1975,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1975,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":2019,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":2019,"length":2,"unicode":"1f310"},{"_":"messageEntityBold","offset":2465,"length":43}],"shape":"<strong >SIEM: от корреляции до расследования</>\n\nПредставим условную ситуацию:\n<blockquote data-break-after=\"\" data-break-before=\"\">1. По учетной записи сотрудника происходит 15 неудачных попыток входа в VPN.\n2. Через минуту вход удается с непривычного IP-адреса.\n3. Затем учетная запись обращается к файловому серверу, с которым обычно не работает.\n4. После этого фиксируется передача большого объема данных.</>\nКорреляционное правило может связать эти события по учетной записи и времени и сформировать сигнал для проверки.\n \nНо сама цепочка еще не доказывает атаку.\n \nСотрудник мог вернуться из командировки, несколько раз ошибиться в пароле и скачать архив для новой задачи.\n \nВозможен и другой сценарий — учетную запись использует посторонний.\n \nАналитику предстоит проверить устройство, историю активности, назначение файлов и обстоятельства доступа. SIEM помогает собрать данные для этой проверки и выделить подозрительную последовательность.\n \nВ первую очередь стоит связаться с сотрудником и верифицировать активность, подтвердить ее легитимность. Многие кейсы решаются уже на этом этапе.\n \nЕсли действия нелегитимны, необходимо изолировать потенциальную точку входа: например, выполнить сетевую изоляцию хоста и блокировку учетной записи VPN.\n \nПосле купирования необходимо определить точку проникновения и принять меры, чтобы предотвратить подобные инциденты в будущем.\n \nВ этом кейсе явно есть риск компрометации учетных данных VPN. Значит, меняем пароль, проверяем хост сотрудника на наличие ПО, которое могло перехватить учетные данные. Параллельно вычищаем следы деятельности злоумышленника и проверяем, не оставил ли он себе обходных путей.\n\n<strong >Что происходит после срабатывания</>\nSIEM может показать алерт в консоли, отправить уведомление, создать тикет или передать сигнал в SOAR для запуска сценария реагирования.\n \nОднако способ доставки — только часть задачи.\n \nДля работы с сигналом нужно понимать:\n \n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> что именно вызвало срабатывание\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> какие учетные записи и системы затронуты\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> почему сигналу присвоен такой приоритет\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> какие данные необходимо проверить дальше\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> кто отвечает за проверку и последующие действия.\n \nПриоритет зависит и от контекста.\n \nПодозрительный вход под учетной записью с широкими правами требует иного внимания, чем похожее событие в изолированной тестовой среде.\n \nАвтоматическая блокировка тоже требует заранее согласованных условий: ошибка может прервать законную работу.\n \nПоэтому связь между обнаружением и реагированием нужно проектировать вместе с владельцами инфраструктуры.\n \n<strong >SIEM не принимает решение вместо аналитика.</> Она должна дать ему достаточно данных, чтобы это решение можно было принять быстро и обоснованно."}">SIEM может показать алерт в консоли, отправить уведомление, создать тикет или передать сигнал в SOAR для запуска сценария реагирования.
   
  Однако способ доставки — только часть задачи.
   
  Для работы с сигналом нужно понимать:
   
• ,"offset":69,"length":277},{"_":"messageEntityBold","offset":1593,"length":33},{"_":"messageEntityCustomEmoji","offset":1853,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1853,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":1888,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1888,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":1932,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1932,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":1975,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1975,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":2019,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":2019,"length":2,"unicode":"1f310"},{"_":"messageEntityBold","offset":2465,"length":43}],"shape":"<strong >SIEM: от корреляции до расследования</>\n\nПредставим условную ситуацию:\n<blockquote data-break-after=\"\" data-break-before=\"\">1. По учетной записи сотрудника происходит 15 неудачных попыток входа в VPN.\n2. Через минуту вход удается с непривычного IP-адреса.\n3. Затем учетная запись обращается к файловому серверу, с которым обычно не работает.\n4. После этого фиксируется передача большого объема данных.</>\nКорреляционное правило может связать эти события по учетной записи и времени и сформировать сигнал для проверки.\n \nНо сама цепочка еще не доказывает атаку.\n \nСотрудник мог вернуться из командировки, несколько раз ошибиться в пароле и скачать архив для новой задачи.\n \nВозможен и другой сценарий — учетную запись использует посторонний.\n \nАналитику предстоит проверить устройство, историю активности, назначение файлов и обстоятельства доступа. SIEM помогает собрать данные для этой проверки и выделить подозрительную последовательность.\n \nВ первую очередь стоит связаться с сотрудником и верифицировать активность, подтвердить ее легитимность. Многие кейсы решаются уже на этом этапе.\n \nЕсли действия нелегитимны, необходимо изолировать потенциальную точку входа: например, выполнить сетевую изоляцию хоста и блокировку учетной записи VPN.\n \nПосле купирования необходимо определить точку проникновения и принять меры, чтобы предотвратить подобные инциденты в будущем.\n \nВ этом кейсе явно есть риск компрометации учетных данных VPN. Значит, меняем пароль, проверяем хост сотрудника на наличие ПО, которое могло перехватить учетные данные. Параллельно вычищаем следы деятельности злоумышленника и проверяем, не оставил ли он себе обходных путей.\n\n<strong >Что происходит после срабатывания</>\nSIEM может показать алерт в консоли, отправить уведомление, создать тикет или передать сигнал в SOAR для запуска сценария реагирования.\n \nОднако способ доставки — только часть задачи.\n \nДля работы с сигналом нужно понимать:\n \n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> что именно вызвало срабатывание\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> какие учетные записи и системы затронуты\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> почему сигналу присвоен такой приоритет\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> какие данные необходимо проверить дальше\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> кто отвечает за проверку и последующие действия.\n \nПриоритет зависит и от контекста.\n \nПодозрительный вход под учетной записью с широкими правами требует иного внимания, чем похожее событие в изолированной тестовой среде.\n \nАвтоматическая блокировка тоже требует заранее согласованных условий: ошибка может прервать законную работу.\n \nПоэтому связь между обнаружением и реагированием нужно проектировать вместе с владельцами инфраструктуры.\n \n<strong >SIEM не принимает решение вместо аналитика.</> Она должна дать ему достаточно данных, чтобы это решение можно было принять быстро и обоснованно."}">что именно вызвало срабатывание
  
• какие учетные записи и системы затронуты
  
• почему сигналу присвоен такой приоритет
  
• какие данные необходимо проверить дальше
  
• кто отвечает за проверку и последующие действия.

,"offset":69,"length":277},{"_":"messageEntityBold","offset":1593,"length":33},{"_":"messageEntityCustomEmoji","offset":1853,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1853,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":1888,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1888,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":1932,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1932,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":1975,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1975,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":2019,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":2019,"length":2,"unicode":"1f310"},{"_":"messageEntityBold","offset":2465,"length":43}],"shape":"<strong >SIEM: от корреляции до расследования</>\n\nПредставим условную ситуацию:\n<blockquote data-break-after=\"\" data-break-before=\"\">1. По учетной записи сотрудника происходит 15 неудачных попыток входа в VPN.\n2. Через минуту вход удается с непривычного IP-адреса.\n3. Затем учетная запись обращается к файловому серверу, с которым обычно не работает.\n4. После этого фиксируется передача большого объема данных.</>\nКорреляционное правило может связать эти события по учетной записи и времени и сформировать сигнал для проверки.\n \nНо сама цепочка еще не доказывает атаку.\n \nСотрудник мог вернуться из командировки, несколько раз ошибиться в пароле и скачать архив для новой задачи.\n \nВозможен и другой сценарий — учетную запись использует посторонний.\n \nАналитику предстоит проверить устройство, историю активности, назначение файлов и обстоятельства доступа. SIEM помогает собрать данные для этой проверки и выделить подозрительную последовательность.\n \nВ первую очередь стоит связаться с сотрудником и верифицировать активность, подтвердить ее легитимность. Многие кейсы решаются уже на этом этапе.\n \nЕсли действия нелегитимны, необходимо изолировать потенциальную точку входа: например, выполнить сетевую изоляцию хоста и блокировку учетной записи VPN.\n \nПосле купирования необходимо определить точку проникновения и принять меры, чтобы предотвратить подобные инциденты в будущем.\n \nВ этом кейсе явно есть риск компрометации учетных данных VPN. Значит, меняем пароль, проверяем хост сотрудника на наличие ПО, которое могло перехватить учетные данные. Параллельно вычищаем следы деятельности злоумышленника и проверяем, не оставил ли он себе обходных путей.\n\n<strong >Что происходит после срабатывания</>\nSIEM может показать алерт в консоли, отправить уведомление, создать тикет или передать сигнал в SOAR для запуска сценария реагирования.\n \nОднако способ доставки — только часть задачи.\n \nДля работы с сигналом нужно понимать:\n \n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> что именно вызвало срабатывание\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> какие учетные записи и системы затронуты\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> почему сигналу присвоен такой приоритет\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> какие данные необходимо проверить дальше\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> кто отвечает за проверку и последующие действия.\n \nПриоритет зависит и от контекста.\n \nПодозрительный вход под учетной записью с широкими правами требует иного внимания, чем похожее событие в изолированной тестовой среде.\n \nАвтоматическая блокировка тоже требует заранее согласованных условий: ошибка может прервать законную работу.\n \nПоэтому связь между обнаружением и реагированием нужно проектировать вместе с владельцами инфраструктуры.\n \n<strong >SIEM не принимает решение вместо аналитика.</> Она должна дать ему достаточно данных, чтобы это решение можно было принять быстро и обоснованно."}"> 
Приоритет зависит и от контекста.
 
Подозрительный вход под учетной записью с широкими правами требует иного внимания, чем похожее событие в изолированной тестовой среде.
 
Автоматическая блокировка тоже требует заранее согласованных условий: ошибка может прервать законную работу.
 
Поэтому связь между обнаружением и реагированием нужно проектировать вместе с владельцами инфраструктуры.
 
SIEM не принимает решение вместо аналитика. Она должна дать ему достаточно данных, чтобы это решение можно было принять быстро и обоснованно.

,"offset":69,"length":277},{"_":"messageEntityBold","offset":1593,"length":33},{"_":"messageEntityCustomEmoji","offset":1853,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1853,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":1888,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1888,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":1932,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1932,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":1975,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":1975,"length":2,"unicode":"1f310"},{"_":"messageEntityCustomEmoji","offset":2019,"length":2,"document_id":"5199884594228257988"},{"_":"messageEntityEmoji","offset":2019,"length":2,"unicode":"1f310"},{"_":"messageEntityBold","offset":2465,"length":43}],"shape":"<strong >SIEM: от корреляции до расследования</>\n\nПредставим условную ситуацию:\n<blockquote data-break-after=\"\" data-break-before=\"\">1. По учетной записи сотрудника происходит 15 неудачных попыток входа в VPN.\n2. Через минуту вход удается с непривычного IP-адреса.\n3. Затем учетная запись обращается к файловому серверу, с которым обычно не работает.\n4. После этого фиксируется передача большого объема данных.</>\nКорреляционное правило может связать эти события по учетной записи и времени и сформировать сигнал для проверки.\n \nНо сама цепочка еще не доказывает атаку.\n \nСотрудник мог вернуться из командировки, несколько раз ошибиться в пароле и скачать архив для новой задачи.\n \nВозможен и другой сценарий — учетную запись использует посторонний.\n \nАналитику предстоит проверить устройство, историю активности, назначение файлов и обстоятельства доступа. SIEM помогает собрать данные для этой проверки и выделить подозрительную последовательность.\n \nВ первую очередь стоит связаться с сотрудником и верифицировать активность, подтвердить ее легитимность. Многие кейсы решаются уже на этом этапе.\n \nЕсли действия нелегитимны, необходимо изолировать потенциальную точку входа: например, выполнить сетевую изоляцию хоста и блокировку учетной записи VPN.\n \nПосле купирования необходимо определить точку проникновения и принять меры, чтобы предотвратить подобные инциденты в будущем.\n \nВ этом кейсе явно есть риск компрометации учетных данных VPN. Значит, меняем пароль, проверяем хост сотрудника на наличие ПО, которое могло перехватить учетные данные. Параллельно вычищаем следы деятельности злоумышленника и проверяем, не оставил ли он себе обходных путей.\n\n<strong >Что происходит после срабатывания</>\nSIEM может показать алерт в консоли, отправить уведомление, создать тикет или передать сигнал в SOAR для запуска сценария реагирования.\n \nОднако способ доставки — только часть задачи.\n \nДля работы с сигналом нужно понимать:\n \n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> что именно вызвало срабатывание\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> какие учетные записи и системы затронуты\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> почему сигналу присвоен такой приоритет\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> какие данные необходимо проверить дальше\n<img data-doc-id=\"5199884594228257988\" data-sticker-emoji=\"🌐\">🌐</> кто отвечает за проверку и последующие действия.\n \nПриоритет зависит и от контекста.\n \nПодозрительный вход под учетной записью с широкими правами требует иного внимания, чем похожее событие в изолированной тестовой среде.\n \nАвтоматическая блокировка тоже требует заранее согласованных условий: ошибка может прервать законную работу.\n \nПоэтому связь между обнаружением и реагированием нужно проектировать вместе с владельцами инфраструктуры.\n \n<strong >SIEM не принимает решение вместо аналитика.</> Она должна дать ему достаточно данных, чтобы это решение можно было принять быстро и обоснованно."}">

Наши соцсети:  ВК | МАХ | ТГ

Основной рост приходится на маркетплейсы, также растет активность на досках объявлений, в мессенджерах и соцсетях. В отчете BrandSecurity разобраны уязвимые категории товаров.

Компания BrandSecurity выпустила аналитический отчет «Нелегальные продажи в интернете 2026: тенденции, отрасли, прогнозы». В нем рассмотрены динамика нарушений прав на бренды, распределение нелегальных предложений по типам площадок и товарным категориям, а также изменения в методах работы продавцов.

За первые шесть месяцев 2026 года BrandSecurity выявила 320 362 нарушения прав на бренды. За год прирост составил 56,9%.

За весь 2025 год в исследуемой выборке было зафиксировано 531 897 нарушений. За первые полгода 2026 года объем выявленных случаев достиг 60,2% от прошлогоднего показателя.

Маркетплейсы сохраняют лидерство по числу нарушений

Основной объем нарушений приходится на маркетплейсы. В первом полугодии 2026 года здесь выявили 223 989 случаев — на 69,9% больше, чем годом ранее. В социальных сетях количество нарушений выросло на 108,4%, до 15 864, в мессенджерах — на 66,3%, до 18 607.

На досках объявлений прирост оказался умереннее — 6,1%, до 35 894 нарушений. В интернет-магазинах показатель увеличился на 1,9%, до 18 817.

«Рост числа нарушений связан с несколькими факторами: расширяется присутствие зарубежных продавцов, продажи распределяются между разными каналами. Особенно заметна динамика среди китайских селлеров. Нередко они используют копии оригинальных карточек и предлагают товары по цене ниже официальной», — отметил Руслан Кривулин, основатель BrandSecurity.

Маркетплейсы сохраняют лидерство по числу нарушений

Аналитики BrandSecurity изучили предложения популярных брендов в нескольких товарных категориях и сравнили долю зарубежных продавцов на маркетплейсах. Такие предложения относятся к зоне риска: зарубежные селлеры чаще всего не могут подтвердить легальное происхождение товаров.

Среди уязвимых категорий:

— Товары для туризма и отдыха — до 93% зарубежных продавцов по популярным брендам.

— Одежда и обувь — до 88% зарубежных продавцов в сегменте одежды премиум-класса.

— Электроника и комплектующие для ПК — до 88% зарубежных селлеров на Wildberries.

— Бытовая химия — до 74% по популярным брендам средств для стирки.

— Косметика и парфюмерия — до 72% в сегменте декоративной косметики.

«Наибольшая доля контрафактной и серой продукции приходится на категории с высоким потребительским спросом и с относительно крупным средним чеком. Такие товары наиболее привлекательны для нелегальных селлеров», — пояснила Елена Козицина, руководитель отдела аналитики BrandSecurity.

Как меняются методы нелегальных продавцов

В отчете отмечается: продавцы адаптируются к усилению контроля. Они искажают названия брендов, меняют оформление карточек и используют фотографии и описания оригинальных товаров. Еще один сценарий — перенос продаж на другие площадки после блокировки объявлений или магазинов.

Один продавец может работать под несколькими названиями магазинов, а после удаления карточки размещать предложения заново. Поэтому при анализе нарушений важно учитывать повторяющиеся признаки: изображения, описания, контакты и другие данные.

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

Подробнее о динамике нарушений, уязвимых товарных категориях и методах работы нелегальных продавцов — в аналитическом отчете BrandSecurity «Нелегальные продажи в интернете 2026: тенденции, отрасли, прогнозы»

SECURITM - адаптивная система управления информационной безопасностью. В одном окне служба ИБ ведёт учёт активов, оценивает соответствие требованиям и стандартам, управляет рисками, защитными мерами, уязвимостями и задачами, отслеживает метрики и автоматизирует рутинные операции. Внешние средства защиты и ИБ-системы подключаются через интеграции и дополняют общую картину безопасности.

От вопроса к данным без ручных выгрузок

ИИ может предложить общий план работы с рисками. Но чтобы ответить, какие риски вашей организации требуют внимания, ему нужны конкретные сведения: какие активы затронуты, что запланировано и кто отвечает за выполнение.

Раньше эти данные приходилось выгружать из системы и переносить в чат. MCP, или Model Context Protocol, - открытый протокол подключения ИИ к внешним системам - позволяет обращаться за ними к SECURITM прямо в ходе разговора.

Вы задаёте вопрос. ИИ ищет и читает данные в SECURITM, затем готовит ответ.

Например:

• "Какие критичные активы у нас без владельца?"
• "Какие риски с высоким уровнем остались без задач?"
• "Какие задачи по ИБ просрочены и кто за них отвечает?"
• "Как изменились метрики за месяц?"

Полученный результат можно уточнить: сгруппировать задачи по ответственным, подробнее разобрать найденные записи или подготовить краткую сводку для встречи.

Так проще обнаружить конкретные пробелы: риск оценён, но работа по нему не запланирована; актив признан критичным, но владелец не указан.

Работайте с привычным ИИ

Подключение рассчитано на инструменты с поддержкой MCP. Среди вариантов - GigaChat, решения Яндекса, Claude, ChatGPT и Cursor. Способ настройки зависит от выбранного клиента.

Можно подключить и локальную модель в собственном контуре. Для этого потребуется поддержка MCP или соответствующее подключение. Такой вариант позволяет работать с данными SECURITM через ваш ИИ внутри инфраструктуры организации.

MCP-сервер дополняет встроенный AI-ассистент SECURITM. Со встроенным ассистентом вы работаете внутри платформы. Через MCP ваш ИИ обращается к SECURITM за данными.

Доступ под вашим контролем

MCP-сервер может работать только на чтение, с гранулярным доступом к отдельным модулям и объектам. Вы определяете, какие данные доступны вашему ИИ. В режиме чтения ИИ не может редактировать риски, изменять записи или закрывать задачи.

Для подключения используется отдельный MCP-токен. Обращения можно ограничить по IP-адресам. Вы также можете использовать локальную модель в собственном контуре.

Качество ответа зависит от полноты данных и возможностей выбранного ИИ. Найденные сведения и предложенные выводы нужно проверять перед принятием решений.

Попробуйте на своей рабочей задаче

Возьмите сводку, которую обычно собираете вручную перед встречей, и попросите своего ИИ подготовить её на основе данных SECURITM. Это понятный способ оценить новую возможность на практике: проверить результат и увидеть, сколько подготовительной работы удалось снять с команды.

Если вы ещё выбираете платформу управления ИБ, будем рады показать этот сценарий на демонстрации и обсудить, как SECURITM поможет организовать работу вашей службы.

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

За последние годы требования к защите информации в республике заметно выросли. Для информационных систем, где обрабатывается информация ограниченного распространения, аттестация системы защиты проводится до ввода в эксплуатацию, а действующий аттестат остаётся обязательным условием обработки такой информации. За нарушение законодательства о персональных данных предусмотрена административная ответственность по ст. 23.7 КоАП РБ.

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

SECURITM относится к классу решений SGRC (Security Governance, Risk and Compliance) – управление информационной безопасностью, рисками и соответствием требованиям. Ключевые документы белорусского регулирования собраны в единую регуляторную базу платформы, что позволяет вести оценку соответствия наравне с российскими и международными требованиями.

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

Для компаний, работающих одновременно в России и Белоруссии, платформа обеспечивает единую точку контроля сразу по двум юрисдикциям без дублирования: белорусский контур можно вынести в отдельную область и получать по нему обособленную оценку.

Работа с белорусской регуляторной базой доступна в SECURITM всем организациям республики, а также российским компаниям с площадками и дочерними структурами в Белоруссии. Демонстрацию возможностей платформы на конкретной нормативной базе можно запросить у вендора.

Компания «СёрчИнформ» представила результаты исследования уровня информационной безопасности в московских организациях за 2026 год. В опросе приняли участие 120 специалистов по ИБ из государственных и коммерческих компаний различного масштаба.

В 2026 году компании чаще сталкивались с ИБ-нарушениями: о внутренних инцидентах сообщили 72% ИБ-специалистов против 59% в 2025 году. Среди инцидентов: утечки данных (53%), внешняя атака через сотрудников (24%), дискредитация компании (19%), фирмы-боковики/сторонняя занятость (18%), промышленный шпионаж/работа на конкурентов (16%), откаты (15%).*

Чаще всего в 2026 году компании сталкивались с попытками слива внутренних регламентов, планов и служебных переписок (55%), персональных данных (54%), информации о сделках, данных корпоративных клиентов и подрядчиков (48%). Об утечках финансовой и технической документации сообщили 30% и 27% респондентов.*

В 2026 году заметно выросла роль ИИ-сервисов как канала утечки. В 2025 году с передачей конфиденциальной информации через ИИ сталкивались лишь 6% московских компаний, в 2026 году – уже 40%. ИИ-сервисы вышли на третье место после мессенджеров (62%) и электронной почты (57%). Также у трети опрошенных утечки происходили через съемные носители и облачные сервисы.*

«В 2025 году ИИ-сервисы замыкали десятку популярных каналов. В этом году ИИ-сервисы уже третьи по популярности, то есть тенденция однозначна – ИИ закрепился как основной канал утечки. Проблема в том, что чаще сотрудники не понимают, какие данные критичны, и загружают их в нейросеть, чтобы быстрее выполнить задачу.

Компании встают перед выбором: запретить сотрудникам использовать ИИ-инструменты и терять конкурентные преимущества или допустить использование ИИ и рисковать конфиденциальными данными. Но запрещать сотрудникам пользоваться нейросетями при этом не обязательно: достаточно определить, какие данные нельзя передавать в ИИ, и контролировать это техническими средствами», – комментирует заместитель генерального директора по инновационной деятельности «СёрчИнформ» Алексей Парфентьев.

Чаще всего виновниками ИБ-инцидентов в московских компаниях становились рядовые сотрудники: с их нарушениями столкнулись 79% опрошенных организаций. Выросла и доля компаний, где нарушителями оказались руководители. Инциденты по вине линейных руководителей отметили 35% организаций против 30% в 2025 году, по вине руководителей направлений – 24% против 22%.*

Чаще всего ИБ-инциденты по вине сотрудников случались непреднамеренно: о нарушениях из-за халатности или под влиянием социальной инженерии сообщили 48% опрошенных. Ещё 34% ответили, что сотрудники нарушали правила умышленно, а 18% московских компаний одинаково часто сталкивались со случайными и намеренными инцидентами.

Главная причина нарушений правил ИБ – желание сотрудников упростить себе работу (78%). Например, сотрудник может переслать рабочие файлы на личную почту, чтобы закончить задачу дома, или поделиться паролем с коллегой. На втором месте финансовая выгода (44%), на третьем – желание получить доступ к информации или ресурсам (41%).*

Большинство компаний, столкнувшихся с ИБ-инцидентами, ограничивались выговором, предупреждением или замечанием (68%). Санкции в виде увольнения применяли к нарушителям почти половина (53%) компаний, столкнувшихся с инцидентами ИБ. Доводили инцидент до суда лишь 14% опрошенных компаний. 14% работодателей никак не наказывали нарушителей.*

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

За такие нарушения компанию могут оштрафовать за утечку персональных данных и незаконную передачу данных за рубеж. Поэтому так называемый «теневой ИИ» становится для организаций реальной угрозой.

Чтобы минимизировать риск экономических потерь и штрафа, организациям необходимо урегулировать в локальных актах правила доступа к информации и ее обработки, в т.ч. с помощью ИИ, довести эти документы до сотрудников, контролировать операции пользователей с защищаемыми данными и объектами ИС», – комментирует специалист по связям с государственными органами «СёрчИнформ» Дмитрий Вощуков.

Почти половина опрошенных (48%) сообщили, что ИБ-инциденты не повлекли для компании последствий. Однако у многих организаций нарушения закончились разбирательствами. Например, трудовые и гражданские споры с сотрудниками возникали у 32% компаний, проверки контролирующих органов – у 13%. Еще 13% опрошенных столкнулись с возбуждением уголовных дел, а 7% – с гражданскими спорами с контрагентами.

* – вопросы с возможностью выбрать несколько вариантов ответов.

«СёрчИнформ» проводит исследование «Ситуация с ИБ в компаниях России» десятый год подряд. Респонденты – специалисты по информационной безопасности компаний из различных отраслей. Опрос проводится в рамках ежегодной серии конференций «СёрчИнформ».

Компания «Газинформсервис» в этом году получила патент на способ, который позволяет обнаруживать такую деградацию и устранять её автоматически (патент на изобретение № 2867439 «Способ и система обучения интеллектуального средства защиты информации»).

Разовая проверка — аттестация или тест на исторических данных — фиксирует качество только в момент теста, а ручное дообучение требует времени и специалистов, и всё это время средство защиты работает хуже, чем могло бы. Запатентованный способ закрывает этот разрыв замкнутым циклом «проверка — оценка — дообучение». Авторы изобретения: учредитель компании Валерий Пустарнаков, заместитель технического директора Лидия Виткова, а также сотрудники лаборатории технологий искусственного интеллекта Сергей Чатоян, Никита Бобров и Ирина Меженева.

Интеллектуальное средство защиты (метод применим к системам классов EDR, NDR, XDR, UEBA, SIEM) помещают в тестовую среду, имитирующую автоматизированную систему. Это может быть виртуальная, аппаратная или гибридная среда, вплоть до участка киберполигона, воспроизводящего реальный защищаемый объект с его трафиком и пользовательской активностью. Средство подвергают серии тестовых воздействий, а его отклики оценивают по частным показателям, например своевременности реагирования и устойчивости к ложным срабатываниям.

Частные показатели сводятся в интегральную оценку с помощью функции нелинейной свёртки, а решение о корректировке принимается по пороговому критерию на шкале желательности. Ключевой элемент метода — адресность дообучения: если порог не достигнут, система находит в откликах именно те блоки данных, которые повлияли на провальные показатели, и дообучает модель только на них, а не на всём массиве. Цикл повторяется, пока средство не выйдет на требуемый уровень.

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

«Измеримость важна и для системы доверия к ИИ, которая сейчас формируется в России. По данным Консорциума исследований безопасности технологий ИИ, около 300 информационных систем в регионах уже используют различные технологии ИИ без учёта актуальных рисков и угроз. В сентябре 2025 года Консорциум направил в Минцифры концепцию федерального реестра доверенных решений ИИ на основе риск-ориентированного отраслевого подхода; реестр рассматривается как репозиторий и полигон тестирования типовых ИИ-решений для государственных информационных систем», — отметила Лидия Виткова.

Отметим, что рабочую группу № 3 Консорциума, которая отвечает за это направление, возглавляет «Газинформсервис», лидер группы — заместитель технического директора компании Лидия Виткова.

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

В рамках встречи эксперты компании «Газинформсервис» представили четыре тематических выступления. Заместитель технического директора Лидия Виткова рассказала о внедрении инноваций в производственный цикл компаний. Далее выступили сотрудники Аналитического центра компании: Алексей Максимов посвятил выступление проведению «Киберарены» и расследованию атак, Глеб Максимов и Екатерина Герлинг рассмотрели использование моделей машинного обучения в информационной безопасности и защиту ИИ-систем, а завершилась образовательная программа квизом «GIS DOU-BLEX», который провёл Максим Федосенко.

Одной из ключевых тем встречи стали возможности профессионального старта в «Газинформсервисе». Студентам рассказали об актуальных вакансиях, а также предложили варианты прохождения производственной и преддипломной практики и стажировки. Участники смогли задать вопросы экспертам, обсудить карьерные перспективы и получить памятный мерч проекта Security Skills.

«Такие форматы позволяют будущим специалистам получить практический опыт в сфере информационной безопасности, познакомиться с рабочими процессами ИТ-компании и применить полученные в университете знания при решении профессиональных задач. Кроме того, участники смогли задать вопросы экспертам, обсудить карьерные перспективы и получить памятный мерч проекта Security Skills», — отметила куратор и идейный вдохновитель Security Skills Александра Гергетт.

Security Skills — образовательный проект компании «Газинформсервис», направленный на развитие профессиональных компетенций студентов, знакомство с актуальными направлениями информационной безопасности и формирование кадрового резерва компании. Проект помогает выстраивать взаимодействие между университетами и работодателем, предоставляя студентам возможность учиться у практикующих специалистов и узнавать о доступных карьерных траекториях ещё во время обучения.

Подробная информация о проекте и регистрация на следующие встречи доступны на сайте проекта.

Модерировал сессию руководитель службы маркетинга ООО «Газинформсервис» Григорий Ковшов. Спикеры: Дражен Вишнич (директор Агентства по информационным и коммуникационным технологиям Правительства Республики Сербской), Владимир Каменецкий (президент ГК «СофтБаланс», резидент «Технопарка Санкт-Петербурга»), Милош Грозданович (заместитель директора по развитию бизнеса Научно-технологического парка г. Ниш, Сербия) и Антон Белоусов (генеральный директор ООО «Киберразведка», резидент «Технопарка Санкт-Петербурга»).

Слово было предоставлено зарубежным гостям — Дражену Вишничу и Милошу Гроздановичу. «Кибербезопасность — тема, которая должна сближать страны, а сотрудничество в этой сфере — одно из самых важных. Для России, Республики Сербской и Сербии принципиален обмен опытом: взаимодействие трёх стран помогает выстроить устойчивую систему киберзащиты. Но важно понимать: сегодня недостаточно реагировать на атаки постфактум. Нужно работать на опережение — развивать решения, которые позволяют предотвращать кибератаки, а не разбирать их последствия. Быть на шаг впереди — вот наша задача», — отметил Милош Грозданович.

Владимир Каменецкий отметил: «Мы видим, что государство уделяет всё больше внимания кибербезопасности: приказ ФСТЭК № 117 устанавливает требования к защите государственных организаций, а заложенные в нём подходы могут стать ориентиром и для коммерческих компаний, особенно работающих в качестве подрядчиков. Не менее важный шаг на перспективу — включение тем кибербезопасности и искусственного интеллекта в школьную программу с 5-го по 11-й класс, ведь основы безопасного поведения в цифровом мире необходимо закладывать с детства».

При этом, по его словам, международные индексы NCSI и Global Cybersecurity Index оценивают наличие законодательства и органов, но хуже отвечают на вопрос, насколько страна реально выдерживает атаки. Он предложил добавить практические показатели: долю успешных атак, масштаб ущерба, время обнаружения и локализации инцидента, время восстановления критических сервисов. В России наиболее значимым примером измеримости он назвал приказ ФСТЭК № 117 с показателями КЗИ и УЗИ.

Своими данными поделился и основатель «Киберразведки» Антон Белоусов: «В „Киберразведке“ мы применяем собственную систему оценки киберустойчивости организаций, регионов и стран. Она учитывает утечки учётных записей, поддельные аккаунты и обнаруженные фишинговые атаки. Показатель риска для Сербии составляет 74 балла из 100 при медианном значении 75 среди 134 оценённых стран. Россия занимает первое место по уровню риска — 81 балл. По нашей методике, российские компании работают в среде с более высоким уровнем киберугроз».

Эксперт подчеркнул, что фишинговые атаки остаются актуальной угрозой, а во многих организациях до сих пор не проводят учебные симуляции таких атак. «По нашим наблюдениям, около 10% сотрудников переходят по ссылкам в фишинговых сообщениях, а около 5% совершают потенциально опасные действия: скачивают и запускают файлы либо вводят данные учётной записи на подозрительных страницах. Регулярные симуляции позволяют проверить реакцию сотрудников и понять, чему следует уделить внимание при обучении», — добавил основатель «Киберразведки».

«Между нашими странами на горизонте ближайших лет потенциал в вопросах кибербезопасности, обмена опытом и лучшими практиками в сфере ИТ и высоких технологий будет только расширяться и расти. Благодаря данным встречам и диалогу сторон заложен прочный фундамент в сфере реальной, практической кибербезопасности. Мы будем и дальше развивать партнёрство и взаимовыгодное сотрудничество в вопросах развития цифровой независимости и суверенитета дружественных нам стран», — резюмировал Григорий Ковшов.

Таким образом, фундамент для сотрудничества действительно заложен, но эксперты предупреждают: без перехода от «бумажных» рейтингов к измерению реальной киберустойчивости партнёрство рискует остаться красивым на словах и уязвимым на практике.