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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так появилась эта серия: 23 фичи Luxms BI, которыми мы гордимся. Это не список «всё, что у нас есть», и не подборка базовых возможностей, которые сегодня есть почти в каждом BI-инструменте. Мы собрали то, что нас самих вдохновляет, и то, что мы чаще всего видим в успешных проектах наших клиентов.

Для удобства мы разделили эти фичи на четыре тематических блока. Начнём с первого блока — архитектура и платформенность, с того, на чём держится всё остальное. В этой статье мы расскажем, как устроена платформа Luxms BI, почему мы сделали ставку на датацентричную модель, как устроена быстрая кастомизация интерфейсов, что такое BI-Magic-Resources, и зачем внутри BI-платформы observable-сервисы. 

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

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

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

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

Привет, Хабр! Я — Ксюша, младший специалист по ИБ в Selectel. 22 сентября 2012 года в России появилась первая программа багбаунти. Сегодня в индустрии уже работают несколько отечественных платформ, которые объединяют тысячи исследователей и десятки компаний. С каждым годом интерес к багбаунти увеличивается: все больше людей принимают в этом участие, а бизнес активнее разрабатывает собственные программы. Если впервые слышите об этих программах или хотите узнать, как они появились, вы обратились по адресу. В статье поделюсь историей возникновения и расскажу, как уже сегодня можно зарабатывать (и учиться) на чужих ошибках.

У коллег весной вышла резонансная статья про особенности выбора жестких дисков для систем поиска аномалий в сетевом трафике на примере 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» про ИБ и ИИ, приглашаю вас к прочтению.

Важным событием позапрошлой недели стало масштабное заражение npm-пакетов червем Shai-Hulud. Эта вредоносная программа нацелена на разработчиков открытого ПО. Она ставит под угрозу данные для доступа к облачным сервисам, выкладывает в общий доступ приватные репозитории. Данная вредоносная операция может быть квалифицирована как атака на цепочку поставок: взлом популярного npm-пакета приводит к компрометации множества других программных решений. На прошлой неделе специалисты «Лаборатории Касперского» подробно разобрали схему работы зловреда Shai-Hulud. Также с высокой вероятностью был определен «нулевой пациент» — первый зараженный пакет в репозитории npm.

Атака начинается с загрузки зараженного пакета из репозитория npm. После установки автоматически запускается вредоносный скрипт размером более 3 мегабайт с названием bundle.js. Он содержит набор легитимных модулей для работы с облачными сервисами Amazon и Google Cloud Platform, инструменты для взаимодействия с GitHub API, а также имеет функциональность для работы с TruffleHog, свободно распространяемой утилитой для поиска ссылок на конфиденциальные источники данных.

Привет! Меня зовут Руслан, я — инженер по ИБ. В IT-сфере работаю уже 12 лет, десять которых занимаюсь информационной безопасностью. За свою карьеру я успел поучаствовать в защите гостайны, поспособствовать появлению регионального ИБ-интегратора, защитить и аттестовать более сотни ИСПДН (информационных систем персональных данных), а также принять участие в разработке отечественного СЗИ (средства защиты информации). В тексте расскажу, как проходит обычный рабочий день специалиста по ИБ в Selectel.

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

25 августа 2025 года компания Google объявила о «новом уровне безопасности для сертифицированных устройств Android». Для защиты против вредоносного ПО принято решение ввести обязательную верификацию разработчиков, которые подписывают Android-приложения (здесь и далее имеются в виду приложения для сертифицированных устройств с предустановленными программами Google, производители таких устройств перечислены здесь).

В данный момент все все APK-файлы в Android должны быть подписаны цифровой подписью с помощью сертификата, прежде чем будут установлены на устройство или обновлены. В будущем, что

После 22:00 у меня случилась проблема с диском U: ёмкостью 2 Гб — на нем частично исчезли файлы и папки, изначально мне показалось, что из-за аппаратного сбоя HDD, но потом я выяснил истинную ужасную причину, о которой нужно знать. Рассказываю, как я с этим боролся.