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

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

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

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

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

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

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

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

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

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

Представляю вам список самых громких 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 года.

В этом обзоре познакомимся с новой версией нашего решения класса EFSS (Enterprise File Synch & Share), предназначенного для организации безопасного обмена файлами и совместной работы с документами — Кибер Файлы. 

Если вы не знакомы с нашим продуктом, рекомендуем прочитать введение к обзору версии 9.2 и обсуждение новинок в версии 9.3.

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

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

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

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

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

SaaS-приложения упрощают жизнь: их можно быстро развернуть, внедрить в работу и легко масштабировать под задачи. Звучит круто, но есть обратная сторона.

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

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

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

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

Прошло уже более 10 лет с момента, когда вопросы обеспечения безопасности критически важных объектов, а затем и объектов критической информационной инфраструктуры (КИИ) прочно обосновались в повестке различных мероприятий, статей и нормативных актов.

Однако частные и узкие вопросы реализации мер защиты могут оставаться актуальными, но недостаточно исследованными даже сейчас. Один из таких вопросов — безопасная интеграция автоматизированных систем управления технологическими процессами (АСУ ТП), принадлежащих разным субъектам КИИ.

На днях прочитал об ограблении банка в Бангладеш, которое похоже на голливудский блокбастер. В статье узнаете:

• Как хакеры подделали SWIFT-запросы, не ломая саму систему?

• Зачем им понадобился обычный офисный принтер и что они с ним сделали?

• Кто стоял за атакой?

Если интересно как устроена работа с Биометрией и что происходит, когда вы проходите в метро по Биометрии - эта статья для вас.

Всем привет! В нашей практике мы часто сталкивались и устраняли последствия такого опасного вида атаки, как Command injection. Злоумышленники используют эту уязвимость для выполнения вредоносных команд, доступа к контролю вашего ПО и кражи данных. Последствия для бизнеса могут быть непредсказуемыми — и репутационными, и денежными из-за простоя процессов и затрат на восстановление. Под катом статья моего коллеги Димы Каплунова, аналитика SOC в К2 Кибербезопасность. Он собрал все, что вам нужно знать о Command injection: метод, лазейки и главное — как выявить атаку пока не стало слишком поздно. 

Недавно мы реализовали интеграцию NeuVector с Deckhouse Kubernetes Platform по запросу сообщества. Тем не менее наш практический опыт показывает, что NeuVector нельзя считать надёжным инструментом обеспечения безопасности кластеров и контейнеров в production-средах.

В статье набрасываем на вентилятор приводим аргументы, подтверждающие эту позицию, несмотря на отдельные сценарии, когда использование NeuVector может быть оправдано. А ещё предлагаем современные и надёжные Open Source-альтернативы.

У коллег весной вышла резонансная статья про особенности выбора жестких дисков для систем поиска аномалий в сетевом трафике на примере PT NAD. Я подумал, что тоже могу добавить что-нибудь в эту копилку. Тем более, что еще в 2018-м году в рамках какого-то закрытого SOC Day для заказчиков я рассказывал про особенности организации хранилищ для событий безопасности в центрах мониторинга безопасности. Пришло время сдуть пыль с архивов, дополнить их свежей кровью и выложить на суд общественности.

Итак, если коллеги рассказывали про хранение данных для систем поиска сетевых аномалий, то я буду рассуждать про решения класса SIEM (Security Information and Event Management), которые собирают и хранят огромные объемы событий безопасности и для которых правильный выбор накопителей и архитектуры хранилища (а вот про это коллеги не рассказывали, сфокусировавшись только на накопителях) критически влияет на скорость записи событий, быстроту поиска, масштабируемость и надежность всей системы мониторинга. Я попробую рассмотреть ключевые факторы, влияющие на этот выбор, – от интенсивности записи и индексации до уровней хранения и облачных решений, а также проанализирую плюсы и минусы различных вариантов, давая рекомендации под разные сценарии. И хотя в заголовке статьи упоминается только SIEM, описанные рекомендации подойдут для многих средств защиты, активно пишущих, хранящих и обрабатывающих события ИБ.

Все мы слышали про FraudGPT и WormGPT, и про такие атаки как Morris II, imprompter, EchoLeak. Но это все детский сад, или даже скрипткиддерство.

А что насчет использования генеративных способностей LLM в целях киберпреступности в автоматизированном режиме? Да, нарушители используют GenAI-модели для создания полезной нагрузки вируса.

BlackMamba, SkyNet, PromptLock и s1ngularity - если вы хотите узнать, что это за инциденты и какой среди них белая ворона, то я, автор канала «Борис_ь с ml» про ИБ и ИИ, приглашаю вас к прочтению.