Информационная безопасность *

Ситуация: пользователь зашёл на сайт. Фактически его данные уже обрабатываются метрическими программами (файлами cookie), хотя согласия на это он не давал. Пользователь не хочет, чтобы его данные собирались и обрабатывались, поэтому покидает сайт. Но данные уже получены. Что делать в этой ситуации? На каком  основании можно обрабатывать данные пользователя сразу при входе на сайт? 

Слово «антивирус» сейчас для некоторых звучит как анахронизм, что-то из 90-х. Ну какой же, помилуйте, антивирус, когда тут иногда глубокоэшелонированная защита не спасает?!

На прошедшем в мае PHDays мы обсудили с ведущими вендорами и экспертами, как изменился рынок защиты конечных устройств и какие тренды сейчас определяют развитие антивирусных технологий.

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

Если вам интересно, жив ли пациент антивирус и как себя чувствует этот класс систем защиты информации — добро пожаловать под кат.

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

Сегодня с вами Дмитрий Ларин, руководитель продуктового направления по защите баз данных и Александр Хребтов, аналитик группы компаний «Гарда», и мы поговорим о способах защиты баз данных. После 2022 года многие российские компании оказались в ситуации, когда привычные инструменты управления базами данных стали недоступны. Миграция на отечественные СУБД обострила вопрос: как защитить критические данные в условиях, когда стандартные средства больше не работают?

В этой статье мы покажем, как справляться с основными угрозами безопасности СУБД, почему сертификация не спасает от инсайдеров и каким образом системы класса Database Firewall решают эти задачи.

Увидела провокационную статью на Medium, которая собрала довольно положительный отклик. Считаю, что грех таким не поделиться! Вдруг, кому-то будет полезно. 

Привет! Меня зовут Юрий Гуз, я ведущий разработчик команды IAM в MWS Cloud Platform. Мы продолжаем цикл статей о том, как устроен IAM в нашем облаке. Сегодня поговорим о технологии, которая стирает границы между вашей корпоративной IT-инфраструктурой и MWS, — о федерации доступов или просто федерации.

Мы уже рассказывали в статье, как мы делаем IAM для облака MWS. И описали там один из способов зайти в наше облако — использование MTS ID. Способ надёжный и удобный, если MTS ID у вас, конечно, есть. А что, если ваш провайдер удостоверений — это ваш корпоративный Active Directory, Google Workspace или Keycloak? Вам ведь не хочется заводить каждому сотруднику ещё один аккаунт, плодить лишние пароли и ломать уже выстроенные процессы с двухфакторной аутентификацией и ролевой моделью.

На этот случай у нас есть ответ — наша новая фича «Федерация». Она позволяет сотрудникам заходить в MWS с помощью их привычных рабочих учётных записей. Давайте разберёмся, как это работает и зачем нужно.

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

Родителям важно не просто «включить фильтр» или «запретить TikTok», а выстроить долгосрочное доверие, навыки и культуру диалога. Именно поэтому в последние годы появляются инициативы, направленные на помощь семьям в этой задаче. Одна из них — образовательный раздел по детской цифровой безопасности на сайте Security Vision. Он предлагает рекомендации, объяснённые понятным языком, и инструменты, которые можно применить в повседневной жизни: от «чек‑листов» до сценариев разговора с ребёнком о рисках в интернете.

Многие люди публикуют свои проекты на github-подобных git-хостингах, для обеспечения общего доступа (это даёт множество преимуществ во многих случаях).

Часто, ввиду неопытности, при публикации, люди сливают чувствительные данные (в частности токены Telegram-ботов).

Так уж вышло, что я сел писать статью о нашем с Саней (@MrKaban4ik) приключении в багбаунти. Сразу предупреждаю: бывалым исследователям наша история покажется не самой захватывающей. Она не о сложных цепных эксплойтах, а о самом начале пути — о том, как ты делаешь первый шаг на площадке и, затаив дыхание, ждешь вердикта по своему первому отчету. Именно эти первые «хваты» вселяют ту самую уверенность, что ты на правильном пути.

{Багбаунти-кидди презенс}

Чуть предыстории. НЕБОЛЬШАЯ ИСТОРИЧЕСКАЯ СПРАВКА НА 5 МИНУТ. Февраль 2025 года.

Мы с Александром часто участвуем в CTF в рамках студенческой команды Capybaras. Недавно закончился Чемпионат России по спорт проге ИБ, мы написали квалы на чемпионат банка РФ и нас зовут в Екатеринбург на Уральский форум. Вуз платит — едем. К этому моменту мы знаем о вебе что он существует и что если нет никаких ограничений на загрузку можно загрузить файлик.php который может быть шелом и как то магически команды на OS исполняет. О багбаунти мы слышали, но не седели особо — потому что просто не знаешь что искать. Мы с Александром собираем вещи, едим в Сочи и оттуда летим в Екатиб. Хотя давайте меньше деталей, вы же тут не до вечера собрались читать. В общем‑то первый наш форум по ИБ, много вендоров и лекций в молодежной программе. Знакомлюсь с ДВФУ‑шниками, до сих пор {heart}. Но вернемся к форуму. Среди вендоров был и BI.ZONE. Интерес конечно же у меня к нему был потому что они недавно выпускают Threat Zone и как только открылась выставка, а у нас шла кибербитва — я решаю незаметно сбежать и сходить залутать заветный журнальчик. Подхожу к стенду, решаю потыкать стендик и подходит какой‑то тип в черном костюме и начинает спрашивать знаком ли я с продуктами компании, я жестко говорю что знаю EDR и какой то прикол с жуками, называемый bugbounty. А этот тип говорит: «Я глава этого продукта». Таким образом мы познакомились с человеком по имени Андрей Левкин — который сыграет на самом деле большую роль в том, чтоб мы начали багхантить. Форум заканчивается и мы едем домой.

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

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

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

Инфраструктурные сбои всегда были частью реальности, но теперь стали частыми. Масштабы разные, но вывод один: полагаться только на бэкап — всё равно что держать огнетушитель и верить, что им удастся потушить пожар целого здания. И если бэкап — это огнетушитель, то DR (disaster recovery) — это план эвакуации. Бэкап может «сбить пламя в одной комнате», но если «горит весь этаж» — без плана выбраться из здания шансов мало. Сегодня, когда практически любой бизнес завязан на IT, наличие рабочего плана аварийного восстановления перестало быть «опцией для корпораций». Это обязательный элемент выживания. Вопрос только в том, готова ли ваша инфраструктура к сбою?

В недавних обсуждениях одного из вида мошенничества с кредитными картами у меня родился комментарий: «Оптимальный уровень мошенничества больше нуля».

Это утверждение контринтуитивно, и может показаться, что я стараюсь быть слишком умным. Но вам стоит этому поверить.

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

Представляю вам список самых громких CVE сентября — в нем и реально опасные штуки, и те, кто просто громко лает, но не кусает.

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

На связи Максим Митрофанов, ML-лид команды Application Security в  Positive Technologies. Мы занимаемся прикладными вопросами машинного обучения по направлению безопасной разработки, регулярно изучаем новые технические репорты и доменные статьи, разбором одной из которых я и хотел бы поделиться с вами.

Исследуя подходы к оценке больших языковых моделей в разрезе безопасной разработки, мы наткнулись на статью »LLMs Cannot Reliably Identify and Reason About Security Vulnerabilities (Yet?): A Comprehensive Evaluation, Framework, and Benchmarks», которая посвящена анализу применения LLM в задаче обнаружения уязвимостей в исходном коде. 

Перевод фрагментов статьи, представленных в обзоре, не является дословным. Разбор содержит личные комментарии и размышления, возникшие в процессе чтения, и, на мой взгляд, будет особенно интересен специалистам по информационной безопасности и ML-инженерам, внедряющим ИИ в R&D-процессы компаний.

Подоспела подборка необычных ИБ-инцидентов и новостей, о которых мы узнали в прошлом месяце. В сентябре обсуждали: новые детали в деле Coinbase, еще одну дырявую AI-платформу, очередные находки кибер-исследователей в американском общепите.

В прошлой статье мы рассмотрели новые поправки в законодательстве об административной и уголовной ответственности за правонарушения в сфере персональных данных (ПДн). Дорогие Операторы ПДн, как вы там? Успели подать уведомление в Роскомнадзор, победив перебои в работе портала? Приступили к выстраиванию правомерных процессов обработки ПДН и системы их защиты?

Как мы знаем, Федеральный закон от 27.07.2006 г. № 152-ФЗ «О персональных данных» призван в первую очередь защищать права и свободы граждан, поэтому важно его соблюдать не с точки зрения защиты от штрафов, а с точки зрения защиты ПДн граждан. Нововведения в КоАП и УК РФ заставили Операторов собраться и все-таки заняться пробелами в обработке и защите ПДн в их организациях. На мой взгляд, это послужило первым шагом в налаживании диалога с регуляторами и к действиям, направленным в первую очередь на выстраивание грамотной защиты данных граждан.

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

Более 50 % приложений вызывают высокорисковые API браузера, что может быть признаком наличия вредоносного кода. Почти 64 % загружают скрипты с хостов за пределами РФ. Более 70% компаний рискуют получить штрафы от 1 до 18 млн. руб. за сбор ПД с использованием баз данных, размещенных за пределами РФ.

Разбираем результаты исследования безопасности frontend-приложений 3000 крупнейших российских компаний за первое полугодие 2025 года.

Законодательство в области персональных данных активно меняется, а институт согласий на обработку ПДн серьезно трансформируется. Согласия теперь должны оформляться отдельно от других документов, а управлять ими скоро в полной мере будет возможно через Госуслуги.

Меня зовут Никита Козин. Я – Data Protection Officer в БФТ-Холдинге, отвечаю за организацию обработки ПДн более 3000 сотрудников. В статье я делюсь разбором основных нюансов, возникающих при взятии согласий на обработку ПДн.

Я раньше работал обычным безопасником. Кто-то называет таких «ИБшниками», кто-то — «параноиками», кто-то — «тем самым занудой, который мешает жить».
Каждый день у меня был один и тот же диалог:

• Тимлид: «У нас релиз в пятницу, отстань со своим сканированием».
• Менеджер: «В бюджете только Jira и пицца, какие ещё 15 миллионов за софт?»
• Разработчик: «Код сгенерил AI, билд прошёл, значит, всё норм».

Привет! Я Саша Епихин, CTO zVirt. В прошлой моей статье речь шла о том, как oVirt стала самым зрелым Open Source ПО для виртуализации и о том, почему мы в Orion soft выбрали разработку на базе этого решения, а не пошли другим путем. Я упоминал, что мы давно ушли от модели форка: oVirt — это только проверенное ядро, а всю дополнительную функциональность мы разрабатываем «поверх» него сами. Можно сказать, мы не просто натянули новые обои, а сделали капитальную пристройку с ремонтом. Это позволяет и получать обновления сообщества, и отправлять в него багфиксы, и развивать свое комьюнити.

Важно понимать контекст: в 2024 году oVirt официально осталась без поддержки разработчика Red Hat, который перестал выпускать для нее обновления безопасности. Любой продукт, оставшийся без техподдержки, опасен для бизнеса. Но zVirt — это не просто локализованная версия oVirt. Это эволюция платформы, которая не только добавляет новые функции, но и решает проблемы безопасности и стабильности исходного кода.

В этой статье я хочу рассказать подробнее, чем именно мы отличаемся от oVirt. Начну с доработок по стабильности и безопасности.

В кибербезопасности легко застрять в «режиме пожарного»: тушишь инцидент за инцидентом, закрываешь уязвимости, реагируешь на новые требования регуляторов. Работа кипит, но назвать это полноценным развитием сложно — все ресурсы уходят на решение тактических задач. 

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

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