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

1 марта 2026 г. вступил в силу приказ ФСТЭК России № 117 от 11.04.2025, который заменил приказ № 17 и распространил требования по защите информации не только на ГИС, но и на иные информационные системы государственных органов и учреждений. А поправки к 187-ФЗ, принятые в 2025 г., уточнили состав субъектов КИИ и усилили требования по взаимодействию с ГосСОПКА. Содержательно это не революция, набор мер защиты не стал принципиально иным, но изменился фокус проверки. Автор: Антон Рысев, директор по правовым вопросам, Ideco Приказ № 117 [1] требует реализовать базовые меры, адаптировать их к конкретной архитектуре, проверить их применимость с учетом актуальных угроз и, при необходимости, обосновать компенсирующие решения. Это означает, что при проверке будут анализироваться не только документы и перечень внедренных средств, но и то, как именно они встроены в инфраструктуру и каким образом управляются. Предметом оценки становится архитектура: сегментация сети, разграничение сред, контроль ме

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

С каждым годом цифровые угрозы для брендов – скам, фишинг или незаконное использование интеллектуальной собственности – демонстрируют высокую степень автоматизации и использования новых генеративных моделей для наполнения мошеннических страниц фейковым контентом. Для противодействия подобным киберугрозам нужно быть гораздо быстрее злоумышленников. Автор: Станислав Гончаров, руководитель департамента Digital Risk Protection, F6 Типичная ситуация: найден фишинговый сайт, закрыт – и спустя время он появляется снова с другим доменом или слегка измененным контентом. Формально это новый инцидент, по сути – продолжение той же схемы. При росте таких случаев возникают повторяющиеся задачи: ресурс приходится заново находить, проверять связь с предыдущими, обновлять статус и отслеживать изменения. В итоге значительная часть времени уходит не на новые угрозы, а на перепроверку уже известных. Из этого мы сделали простой вывод: если система требует от аналитика регулярно возвращаться к одним и тем ж

По итогам 2025 г. количество вакансий по профессиям в области информационной безопасности выросло на 26%. При этом в ИТ-секторе и на рынке в целом наблюдается снижение числа предложений. Такая динамика говорит о востребованности технологий и экспертизы по ИБ в цифровой экономике, а также о реальной готовности компаний увеличивать инвестиции в это направление. В 2025 г. на российском рынке труда в целом число вакансий сократилось на 13% по сравнению с 2024 г. Аналогичная отрицательная динамика наблюдается и в ИТ-секторе, где компании переходят от этапа активного масштабирования к оптимизации и повышению эффективности существующих процессов. На конец марта 2026 г. рынок труда в кибербезопасности показывает стабильную динамику, начатую в 2025 г.: количество вакансий выросло на 24% год к году, в то время как спрос на ИТ-специалистов упал на 18%. Сокращение числа вакансий в ИТ говорит о том, что компании сместили фокус со сверхбыстрого роста на модернизацию текущих проектов, а также на разв

Для специалиста по ИБ киберинцидент – это аномалия в логах, срабатывание системы обнаружения вторжений или зашифрованные файлы на сервере. Для юриста – юридический факт. Разница в подходах часто становится причиной конфликтов внутри компаний: технари удаляют следы, чтобы восстановить бизнес-процессы, а юристы потом не могут доказать вину злоумышленника или обосновать страховой случай. Автор: Константин Саматов, эксперт BISA (Ассоциация по защите деловой информации), член ICSA (Международная ассоциация корпоративной безопасности), член Ассоциации судебных экспертов В праве точность формулировок определяет применимую норму закона. Давайте выстроим иерархию указанных выше понятий. Инцидент информационной безопасности [1] – это одно или несколько нежелательных или неожиданных событий информационной безопасности, которые с высокой степенью вероятности могут привести к компрометации в бизнес-процессах и создают угрозы для ИБ. Например, уничтожение или повреждение документов – это инцидент ИБ

Смарт-контракты пишутся быстрее, чем их успевают нормально проверять. Ошибки при этом каждый раз разные – от простых просчетов в логике до сложных сценариев с оракулами и внешними протоколами. Разбор каждого инцидента занимает время, а их становится все больше и больше. В какой-то момент проблема сводится уже не к сложности, а к объему: ручной аудит не успевает покрывать все, что появляется. Автор: Александр Подобных, руководитель отдела аналитики и крипторасследований VeroTrace, руководитель комитета по безопасности цифровых активов и противодействию мошенничеству АРСИБ, судебный эксперт (компьютерно-техническая и экономическая экспертиза), член СРО АСЭ “Центр судебной экспертизы” По данным аналитической платформы DeFiLlama, которая отслеживает крупные инциденты в Web3, с 2018 г. совокупные потери превысили $15,8 млрд. Из них более $7,1 млрд пришлось на взломы DeFi-протоколов и около $2,9 млрд – на атаки на кроссчейн-мосты. При этом инциденты отличаются не только масштабом, но и приро

Если убрать все красивые формулировки, проект начинался довольно приземленно. Нужно было развернуть систему резервного копирования в инфраструктуре ЦОД так, чтобы она выдерживала рост данных, не падала при отказах и нормально администрировалась. В принципе, обычная инженерная задача. Но по мере проработки стало понятно, что вопрос не в том, как поставить СРК, а в том, как встроить ее в существующую инфраструктуру так, чтобы она не унаследовала все ее риски. Автор: Альберт Богданов, менеджер продукта RuBackup (входит в “Группу Астра”) Сначала сделали то, что делают почти всегда, – аккуратно сегментировали сеть. Выделили подсети, использовали VLAN, развели трафик. Управление отдельно, потоки данных отдельно. Это выглядело как стандартная практика: меньше связности, меньше шансов случайного доступа, проще контролировать, кто куда ходит. На этом этапе все выглядело вполне традиционно. Дальше перешли к хранению. Разграничение доступа реализовали на уровне СХД. Каждый пул данных закрепили за