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

«Хлебом не кормите – дайте разработать новые документы и внести правки в старые!»

Слова, которые за 10+ лет юридической практики я не слышала от бизнеса ни разу.

И крупная компания, и ИП воспринимают работу над документами как не самую приятную, но неотъемлемую часть ведения деятельности. Даже небольшая ошибка может привести к серьезной ответственности и колоссальным рискам. В статье рассказала, где взять шаблоны документов, за которые не будет стыдно перед Роскомнадзором, Минздравом и пациентами

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

На самом деле, здесь важно потратить время на то, чтобы распознать STL-контейнер по косвенным признакам, быстро понять, где какие данные лежат, типизировать их и идти дальше. В новой серии публикаций мы расскажем о самых распространенных контейнерах STL и начнем с std::vector.

NAC-системы долгое время ассоциировались с “монстрами” вроде Cisco ISE или Aruba ClearPass. Но что, если собрать российский NAC из модулей «Медведь», «Лиса» и «Заяц», поставить их на страже сети и попробовать закрыть те же сценарии?

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

Эта статья — часть цикла о NAC-решениях, которые мы разбираем в нашей сетевой лаборатории. На этот раз в фокусе Eltex NAICE — новичок в области контроля доступа, но далеко не новичок в мире сетей.  Разберёмся, как он устроен, какие задачи реально закрывает и насколько уверенно чувствует себя на фоне более привычных NAC-систем. 

В Git in Sky мы последние полтора года плотно занимаемся безопасностью AI-контуров: аудируем интеграции, разбираем архитектуру доступов, помогаем командам выстроить нормальный контроль над тем, что происходит между их данными и языковыми моделями.

За 2025-2026 годы произошло достаточно публичных инцидентов с AI, чтобы написать большую статью. И призвать всех, кто работает с AI-решениями, обращать внимание на безопасность.

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

Причина в том, что речь идёт не об одной точке контроля, а о распределённой системе, где итоговое поведение формируется на пересечении трёх слоёв: централизованного управления, DPI/ТСПУ как контура распознавания и сети оператора как среды исполнения. Именно эта многослойность и объясняет наблюдаемую неравномерность.

Приветствую, Хабр!

Меня зовут Владислав Тимашенков, я занимаюсь автоматизацией тестирования в ГК Infowatch.

Наша команда столкнулась с популярными болями автотестов для API:

- одно изменение в API требует обновления нескольких тестов;
- проверка структуры ответа распределена по тестам и не централизована;
- валидация вложенных структур и генерируемых полей требует дополнительного кода.

И мы задались вопросом: какой инструмент для валидации контракта нам подойдёт?

В этой статье расскажем о нашем переосмыслении подхода к тестированию API с помощью внедрения Pydantic.

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

Редакция MIT Technology Review в своем ежегодном обзоре выделила 10 направлений, которые сегодня лучше всего показывают, куда движется искусственный интеллект — от новых архитектур и агентных систем до вопросов безопасности, регулирования и общественного сопротивления.

Если коротко: После дефейса сайта нашего знакомого из-за утекшего пароля от админки мы поняли, что управлять доступами нетехнической команды (редакторы, SEO, подрядчики) через VPN или статические IP - это боль. Существующие proxy требовали рестартов и рулились конфигами. В итоге мы написали свой forward-proxy на Go, где доступ выдается токеном через расширение браузера, а правила (TTL, лимиты трафика, доступные домены) применяются на лету без разрыва соединений.

Привет! Я Максим Чеплиёв, менеджер продукта Staffcop, одного из ИБ-сервисов Контура. Расскажу, как мы разрабатываем Staffcop так, чтобы он не нагружал безмерно IT-инфраструктуру клиента. Сразу оговорюсь, что не буду рассказывать о технической реализации на уровне кода, но обращу внимание на уровень архитектуры и стратегических решений.

Ещё пять лет назад Gartner предсказывал, что эксплуатация уязвимостей API станет самым частым вектором взлома приложений и сервисов. Сегодня этот сценарий атак стал практически нормой. Из-за этого API превратились в полноценный бизнес-актив, к которому, по-хорошему, должны применяться те же требования по безопасности и надёжности, что и к любому другому продукту. Однако на практике с этим возникают проблемы.

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

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

Юрий Подгорбунский, Security Vision

Введение

Требования к безопасности критической информационной инфраструктуры (далее – КИИ) установлены Федеральным законом от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» (далее – Федеральный закон).

Цель Федерального закона заключается в предъявлении требований безопасности для обеспечения устойчивого функционирования КИИ при проведении в отношении ее компьютерных атак.

Основные понятия

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

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

Остальные основные понятия в статье будут рассматриваться ниже последовательно. 

Что же такое КИИ?

В целом КИИ – это объекты КИИ, а также сети электросвязи (сети операторов связи), используемые для взаимодействия таких объектов.

А сами объекты КИИ — это следующие системы и сети:

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

Герой этой статьи, Sony BMG, испытывала к пиратам такую личную неприязнь, что кушать не могла решила встроить защиту от пиратства на свои диски, причем защита была настолько капитальной, что формально являлась чистым руткитом, безальтернативно устанавливаемым всем PC-пользователям. Надо ли говорить, что как только о рутките стало известно, им воспользовались все, кто мог, кроме самой Sony.

Иногда доступ во внутреннюю сеть — это не начало атаки, а тупик. Именно в такой ситуации я оказался в самом начале.

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

Кратко напомню отправную точку: в ходе тестирования внешней инфраструктуры заказчика нам удалось получить доступ во внутреннюю сеть через туннелирование. Чтобы не дублировать материал, отмечу лишь, что схема была реализована по подходу, описанному у моих друзей из компании «Deiteriy Lab» в статье - https://habr.com/ru/companies/deiteriylab/articles/920064/. Способ отличный и полностью рабочий, советую взять на вооружение. Для общего представления приведу схему подключения, которую мы использовали (так же взята из статьи).

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

Black-box подразумевает, что у пентестера нет никакой внутренней информации: ни списков IP, ни учётных данных, ни описания архитектуры. Только доменное имя - и вперёд. Звучит как ограничение, но на практике это зачастую преимущество: вы смотрите на инфраструктуру глазами реального злоумышленника.

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

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

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

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

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

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

Уже потом вспомнились странности: слегка «плывущая» картинка на онлайн-встрече и необычный, размытый фон.

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

Во время теста мы не придали значения странным техническим проблемам: обрывы связи, зависания, проблемы со звуком.

На финальном этапе «не самый гадкий утёнок» внезапно превратился в настоящего американского белоголового орлана. Когда обсуждали условия работы и зарплату, её английский звучал практически как родной. Лексика, грамматика, подача, скорость речи — уровень как минимум телеведущего новостного блока CNN.

Хабр, привет! На связи Алина Байрамова, аналитик-исследователь угроз кибербезопасности R-Vision.

В этой статье я разберу уязвимость нулевого дня в TrueConf Server (CVE-2026-3502), связанную с механизмом обновлений, и то, как она может быть использована для компрометации изолированных инфраструктур через доверенный канал распространения ПО.

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

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

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

Статья будет без ИИ мусора и прочего пустословия. Обсудим способы выживания на операционной системе Android в тяжелых условиях.

«Можно, я не буду регистрироваться — давайте обсудим всё, как раньше?» — возмутился старый клиент одного уважаемого сервиса, когда ему предложили завести аккаунт на новой платформе.

Медицинскую клинику у приличных людей сегодня выбирают не по рейтингу, не по врачам и не по локации. А по тому, в чьих руках окажется анамнез после лечения. Попадали ли когда-нибудь анализы её пациентов в открытый доступ? Если нет — можно рискнуть. Гарантий, впрочем, никаких.