Журнал «Информационная безопасность»

NGFW – один из самых важных источников контекстных данных для SOC, но его ценность раскрывается только при глубокой и корректной интеграции с SIEM: когда события не просто собираются, а нормализуются, обогащаются и анализируются в связке с другими источниками. Автор: Василий Кочканиди, аналитик RuSIEM NGFW фиксирует сразу несколько измерений в одном событии: пользователя, устройство, приложение и направление доступа. Поэтому он работает не просто как сетевой, а как поведенческий сенсор. Через него проходят и нормальные бизнес-сценарии, и первые, еще неоформленные признаки проблем – обход политик, странные приложения, нетипичные направления трафика. Нередко именно здесь атака начинает быть заметной раньше, чем ее подхватывают EDR или антивирус. При этом NGFW часто воспринимают утилитарно – как шумный источник сетевых логов, к которому обращаются уже после инцидента. Такой подход сильно обесценивает его роль. На самом деле NGFW – один из немногих источников, который позволяет связать сет

Вы замечали, что большая часть образовательного контента уже давно доступна в сети? Этот массив информации используют модели искусственного интеллекта как исходные данные и выдают пользователю в сжатом и удобном виде. Проблема в том, что такой формат обучения не формирует понимания, как достигается результат. Авторы: Виктор Минин, председатель правления АРСИБ, руководитель направления “Цифровой наставник” Всероссийского общественного движения наставников детей и молодежи Георгий Песчанских, д.э.н., к.ф.-м.н., профессор математики и ИТ, доцент кафедры специальных дисциплин В лучшем случае человек запоминает источники информации, в худшем – осваивает искусство формулирования запросов. Да, это допустимо на этапе первичного знакомства с темой, но современные ИИ идут дальше, имитируя осмысление и выдавая готовые ответы. Само по себе это не плохо, но результат работы алгоритма с известным массивом данных не создает нового знания и не формирует у человека навыков обработки информации. Алгорит

Исследование показало, что безопасность данных и соответствие 152-ФЗ является приоритетом при выборе системы. Участники исследования оценивали, насколько сильно влияет на выбор решения каждый пяти ключевых факторов: простота внедрения и использования, безопасность, аналитические возможности, удобство использования и стоимость продукта. Для микробизнеса безопасность CRM стоит на первом месте, вместе с простотой внедрения системы – важность этих факторов оценивается в 44%. Схожие оценки безопасности дают средний и малый бизнес – 45% и 41% соответственно. Аналитики называют безопасность в числе ключевых технологических трендов развития сегмента CRM в ближайшем будущем. Причем этот тренд является специфическим для российского рынка – растет запрос на защиту CRM и данных в ней, ужесточение требований к возможностям управления идентификациями и правами пользователей. На фоне учащающихся атак через учетные записи и ужесточения ответственности за утечки чувствительных данных, бизнес ожидает бо

Система SGRC умеет почти все, но в реальности работает только там, где ее не пытаются использовать просто как красивую витрину. Мы собрали мнения экспертов: что буксует, а что, наоборот, дает неожиданный эффект. Никакой теории – только то, что видно изнутри. Основное, что оказалось проще – это этап внедрения. GRC – это комплексная система с обширной функциональностью. На начальном этапе компаниям нужно время для настройки системы, внедрения в бизнес-процессы, подключения к работе ответственных подразделений. Компании часто беспокоятся, что это долгий и сложный процесс, но фактически все проходит значительно проще и быстрее. Как правило, на первых этапах знакомства с продуктом его ключевые процессы кажутся наиболее сложными – оценка рисков, проведение аудитов. На деле оказывается, что вся связанная с ними функциональность давно прошла проверку реальными кейсами, учитывает лучшие практики и готова к быстрому старту. Настоящие сложности начинаются на стыке настроек и организационных вопро

Блокчейн-системы применяются в государственном управлении и финансовой инфраструктуре – от МЧД до ЦФА, однако на практике остаются изолированными, а задача безопасного обмена данными между Web3-АС до сих пор не имеет устоявшихся стандартов и готовых решений. С учетом требований регуляторов к взаимодействию операторов ЦФА идет поиск архитектурно и криптографически корректных механизмов межсистемного взаимодействия – в том числе на базе ГОСТ-криптографии. Автор: Михаил Якушкин, научный сотрудник ЦТРР СПбГУ, старший преподаватель МГТУ им. Н.Э. Баумана, призер блокчейн-хакатона Сбера DeFi Hack Большинство автоматизированных систем, построенных на децентрализованной архитектуре и использующих технологии распределенного реестра, в России (далее будем называть их Web3-АС) построены на базе известных блокчейн-платформ – Ethereum (Мастерчейн, Токеон, НРД), Hyperledger Fabric (Атомайз, СПБ Биржа, Спутник ЦФА), Waves (Конфидент, МЧД) и др. Каждая из них по-своему решает задачи масштабируемости и

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

Deception часто сравнивают с Honeypot и считают его усовершенствованной версией. Такая логика понятна: обе технологии используют ложные элементы. Но именно это сходство и вводит в заблуждение. В корпоративной эксплуатации Deception и Honeypot решают разные задачи, по-разному встраиваются в инфраструктуру и дают разный эффект для SOC и для бизнеса. Давайте разбираться. Автор: Екатерина Харитонова, руководитель продукта "Гарда Deception" Начнем с базы. Технологии Deception – это средство обеспечения сетевой безопасности, которое внедряет в корпоративную инфраструктуру ложные, но правдоподобные цифровые объекты и сервисы. Основная цель такой платформы – выявлять попытки нежелательных действий в корпоративной сети и реагировать на угрозу до нанесения реального ущерба бизнесу. На практике это позволяет выявлять даже те атаки, которые обходят сигнатурные средства защиты и защиту периметра сети. Например, в крупной компании администратор-инсайдер использовал сервисную учетную запись для массо

В крупных компаниях стало слишком много инженерии. Команды растут, микросервисы множатся, инфраструктура усложняется, а вместе с ней – и стоимость ее поддержки. Поэтому идея внутренних платформ выглядит естественным ответом на хаос. То, что раньше требовало согласований и ручных настроек, теперь превращается в сервис – Platform as a Service, Publication as a Service, Admin as a Service. Автор: Александр Трифанов, руководитель направления Application Security, "Авито" Тему про платформы мы обсуждали на конференции OFFZONE – международной конференции по практической кибербезопасности, которая ежегодно собирает в Москве тысячи специалистов и сотни экспертов. Создаются такие платформы не ради безопасности. Инициаторами почти всегда выступают уставшие от рутины разработчики или SRE (Site Reliability Engineer, инженеры по надежности сервисов). Главная их мотивация – сэкономить время и ресурсы. Но платформа становится инструментом удобства и стандартизации, а вот безопасность, если и вспомина

Ethereum в модели Proof-of-Stake задумывался как система, в которой валидатор (который отвечает за проверку транзакций и создание новых блоков) остается псевдонимом: набором ключей и правил в протоколе, а не конкретным сервером, компанией или человеком. Формально это действительно так – публичный ключ валидатора не содержит информации о физическом местоположении узла, а сам протокол не хранит и не раскрывает IP-адреса участников. Именно поэтому представители экосистемы нередко утверждают, что получить сведения о валидаторах невозможно. На практике ситуация выглядит сложнее. Автор: Александр Подобных, криптоаналитик аналитического агентства “Opus Magnum”, руководитель комитета по безопасности цифровых активов и противодействию мошенничеству АРСИБ, судебный эксперт (компьютерно-техническая экспертиза) Хотя прямой связи между валидатором и инфраструктурой нет, работа сети оставляет множество косвенных следов. Валидаторы взаимодействуют с сетью через P2P-узлы, получают и отправляют сообщен

Алексей Плешков, эксперт по информационной безопасности с более чем двадцатилетним опытом, о том, как трансформировались ИБ-подходы за последние годы, почему инсайдеры сегодня опаснее внешних атак и зачем ИБ пришлось учить язык бизнеса. – Родился не в Москве, но здесь живу с середины 90-х годов прошлого века. Получил высшее образование в области информационной безопасности в Московском инженерно-физическом институте (МИФИ) по специальности "Комплексное обеспечение информационной безопасности автоматизированных систем". Профессиональный интерес к ИБ сформировался именно в период обучения. С самого начала я фокусировался на сетевой безопасности – уязвимостях, протоколах, операционных *nix-системах, сетевом оборудовании, атаках через интернет, межсетевом экранировании – что в начале 2000-х являлось относительно новым направлением. Но уже востребованным в России и для банковского сектора, и для экономики в целом. Эта тема – сетевая безопасность – меня действительно увлекала и давала простр