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

17 и 18 ноября 2024 года в Балтийском море случился неприятный инцидент: были повреждены два телекоммуникационных кабеля. Один BCS East-West Interlink, соединяющий Литву и Швецию, и C-Lion1 — между Финляндией и Германией. Это вызвало серьезные проблемы с доступом к интернету для некоторых пользователей.  Работоспособность одного кабеля оперативно устранили, буквально через 10 дней, и проблема с доступом разрешилась. Но остался открытым вопрос: что это было? Диверсия или случайное повреждение? Политики поспешили обвинить в этом Россию и Китай — особенно с учетом того, что маршрут судна Yi Peng 3 как раз проходил в этом районе.  И это далеко не единичный случай. Например, в январе 2025 года тот же кабель C-Lion1 повредило якобы уже судно, перевозившее нефть. Давайте посмотрим, насколько это серьезная угроза и как защищают подводные кабели в целом. 

Я пишу о том, как создала fake exploit за 7k $ - фейковая уязвимость, которая не наносит вреда, но выглядит как реальный эксплойт. Это не просто пранк, а образовательный инструмент, позволяющий понять структуру эксплойтов, изучить уязвимости и их демонстрацию. Рассматриваются out-of-bounds write, JIT spray, а также показывается, как можно создавать видимость опасных действий, не причиняя реального ущерба. 

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

В статье рассмотрим базовые концепции мониторинга и обеспечения безопасности кластера Kubernetes, поговорим о распространенных векторах атак, а также разберем способы их обнаружения и метрики, которые в этом помогут.

По просьбе читателей Хабра публикуем без купюр интервью с руководителем Лаборатории цифровой криминалистики и исследования вредоносного кода компании F6 Антон Величко.

Лаборатория цифровой криминалистики и исследования вредоносного кода – одно из старейших подразделений компании F6. Лаба (так уважительно называют подразделение внутри компании) – один из главных поставщиков данных для решений F6 о тактиках, техниках и процедурах, которые используют в своих атаках киберпреступные группировки. Специалисты добывают эти сведения во время реагирований на инциденты и при проведении различных исследований. Больше месяца мы ждали, когда в графике руководителя Лаборатории Антона Величко появится свободный час для того, чтобы рассказать об особенностях национального кибербеза: «Сейчас очень много работы, и она только прибавляется. Последние два года мы неделями не вылезаем из реагирований».

Чем больше систем работают на основе машинного обучения, тем критичнее становится вопрос их безопасности. Умные технологии всё больше окружают нас, и сложно отрицать важность этой темы. С 2019 года на конференции PHDays мы проводим соревнование по спортивному хакингу AI CTF, нацеленное на атаки систем, построенных на машинном обучении. Соревнование проходит в рамках AI Track — направления с докладами на Positive Hack Days, где эксперты в области информационной безопасности делятся опытом применения машинного обучения как для offensive, так и для defensive задач. В 2023 году мы поэкспериментировали с форматом, создав квест-рум, где участникам нужно было обойти три фактора защиты, чтобы выбраться. Однако, прислушавшись к многочисленным просьбам сообщества, мы решили вернуться к нашему традиционному формату CTF.

Каникулы, государственные праздники, любые “внеочередные” выходные дни - это повод для злоумышленников попытаться атаковать. Расчёт атакующих прост: чем меньше “защищающих” специалистов находятся на своих рабочих местах, тем выше шансы пробиться в периметр, закрепиться и нанести ущерб. Так было в прошлом году: в начале мая 2024 года к нам обратились за помощью в расследовании сразу двух серьезных ИБ-инцидентов, произошедших во время майских. Злоумышленники атаковали и уничтожили виртуальную инфраструктуру крупных организаций и на некоторое время парализовали их бизнес-операции. Нормальных выходных не получилось не только у наших дежурных экспертов, но и у представителей пострадавших организаций, которым пришлось променять природу и шашлыки на серверы и логи.  

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

Анализ уязвимости и ограничения Model Context Protocol для подключения инструментов к ИИ-ассистентам.

Узнаете, как оценить риски MCP-интеграций в своих проектах и минимизировать угрозы безопасности

В этой статье я хотел бы рассмотреть вышедший буквально на днях стандарт NIST 800–61r3 «Incident Response Recommendations and Considerations for Cybersecurity Risk Management» (Рекомендации и соображения по реагированию на инциденты для управления рисками в сфере кибербезопасности). Замененный стандарт 800–61r2, выпущенный в далеком 2012 году, был полностью переработан и текущая версия существенно отличается по структуре и подходу к вопросу реагирования на компьютерные инциденты.

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

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

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

Очень популярный проект, но совершенно, на мой взгляд не заслуженно. Качество кода вызывает вопросы, нельзя указывать свои списки с regex паттернами для проверки, и он не умеет отдавать правильный JSON в stdout, что делает его бесполезным автоматизации или пользовании на бэкенде.

Прекрасная возможность:

Использовать Julia – один из лучших языков программирования, который почему-то считается нишевым. Область его применения гораздо шире HPC. Он идеально подходит для решения самых разных задач.

Научиться как правильно публиковаться на GitHub.

Научиться делать линуксовые пакеты.

Привет, Хабр! Меня зовут Марат Сафин, я эксперт по безопасности КИИ и АСУТП в К2 Кибербезопасность. Более восьми лет занимаюсь кибербезом с упором на защиту промышленных объектов и АСУТП. До этого пять лет внедрял и обеспечивал функционирование самих АСУТП.

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

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

Что такое Passkeys?

В 20 лет я планово обновил паспорт. Через пару недель мне позвонили мошенники. С самого начала меня начали «обрабатывать» и для укрепления доверия называть мои ПДн. В разгаре беседы «господа из техподдержки компании N» назвали мои новые паспортные данные!

Я страшно удивился скорости утечки нового паспорта и стало интересно: кто же был источником слива? Тогда я нашел лайфхак, который помогает с высокой вероятностью выяснить, откуда произошла утечка (пользуюсь им и по сей день).

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

Результаты опроса оказались очень показательными: более половины слушателей признались, что не занимаются вопросами информационной безопасности без необходимости. В каком-то смысле статистика ошеломляющая, учитывая, что, по данным Positive Technologies, 98% веб-приложений в принципе могут быть взломаны.

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

В этой статье мы разберём основные недостатки Istio в сравнении с Cilium Service Mesh, чтобы даже начинающий разработчик мог понять, в чём разница и почему некоторые команды выбирают Cilium вместо Istio.

Все привыкли к тому, что безопасность информации — это антивирусы, шифрование, фаерволы и двухфакторная аутентификация. Но задолго до всего этого — в мире без электричества, интернета и даже телеграфа — существовали вполне реальные угрозы утечки данных и методы защиты информации. В статье — реальные кейсы XIV века, средневековые протоколы безопасности, курьезные уязвимости и немного кода (куда без него?).

Если вы думаете, что XIV век — это про рыцарей, чуму и башни без Wi-Fi, то вы, в целом, правы. Но даже тогда существовали конфиденциальные сообщения, шпионаж, защита данных и атаки, которые очень напоминают фишинг, перехват сообщений и даже внедрение в цепочку поставок (правда, поставляли не софт, а людей и письма). Эта статья — попытка взглянуть на ИБ до ИБ, когда информацию защищали не фаерволы, а воск, пергамент и личные головы гонцов.

В корпоративных средах развертывание Active Directory (AD) — де-факто стандарт для администрирования ИТ-инфраструктуры на Windows. Да, в России есть тренд импортозамещения и сопутствующее ему «переползание» на отечественные решения типа Astra Linux-ALD Pro и так далее. Но пока еще Windows стоит много где, и оборона домена AD — это стратегическая задача для большинства организаций.

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

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

Короче говоря, если Active Directory используется в организации здесь и сейчас, не стоит пренебрегать мероприятиями по защите, несмотря ни на что. 

Piklema Predictive — российская компания, разрабатывающая решения для оптимизации горного производства через анализ данных диспетчеризации, цифровые советчики, MES-систем и планирования. За 4 года сотрудничества AvantIT выполнил три миграции их инфраструктуры между облаками (Azure → AWS → GCP → Azure), внедрил Kubernetes и настроил мониторинг, что позволило клиентам Piklema снизить затраты на производство на 15–20%.

Проблема:

Piklema столкнулась с двумя критичными ограничениями. Во-первых, их инфраструктура на Docker Compose не обеспечивала отказоустойчивость, требуемую промышленными заказчиками. Во-вторых, зависимость от грантов вынуждала ежегодно менять облачного провайдера, что приводило к ручным миграциям длительностью до 2 месяцев. Отсутствие мониторинга усугубляло риски: о нехватке ресурсов (например, места на диске) узнавали только после сбоев.

Цель проекта:

Создать гибкую, отказоустойчивую инфраструктуру, которую относительно просто переносить между облаками при завершении гранта. Она должна...