В прошлой статье о VM (от англ. - vulnerability management) мы рассказали, с какими проблемами можно столкнуться при анализе и управлении рисками  Сегодня спустимся на уровень ниже и поговорим об интересных находках, скрывающихся в глубинах готовых VM-отчетов.

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

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

Вспомните обычный рабочий созвон или видеоконференцию – с задержкой связи, эхом или торможением видео. Как правило, это происходит из-за плавающей пропускной способности каналов связи. И если для одних видов трафика (электронная почта или обмен короткими текстовыми сообщениями), подобные задержки некритичны, то для других (голосовые сообщения, видеотрансляции) они становятся серьезной проблемой. При этом безопасность все равно нужно обеспечивать, да так, чтобы средства наложенной защиты, в том числе для ГОСТ-шифрования, не вызывали дополнительных лагов в работе прикладных сервисов. Для этого криптомаршрутизаторы (они же криптошлюзы) должны поддерживать качество обслуживания (Quality of Service – QoS) различных видов трафика, которые конкурируют между собой за ресурсы различных каналов. В этой статье мы разберем, как обеспечивается QoS в зарубежном оборудовании, и изучим нюансы внедрения этих механизмов в российские криптошлюзы.

Объем данных для хранения и обработки растет с устрашающей скоростью – к 2025 году он может достичь 175 зеттабайт (1 зеттабайт = 1 трлн гигабайт). Вместе с ним увеличивается и число уязвимостей, которые становится все сложнее найти и уж тем более управлять ими. Добавьте к этому нехватку финансирования и квалифицированных кадров, и уже понимаешь, что одним сканером уязвимостей и пачкой pdf-отчетов тут не обойтись. В этом посте мы опишем основные проблемы в процессах Vulnerability Management (VM) и ищем способы их решения.

Прошлый год проходил под эгидой вынужденного импортозамещения: вендоры ИТ и ИБ уходили, забирая с собой обновления, сигнатуры и лицензии.  А хакеры радовались уязвимостям, которые компании просто не могли закрыть. Словом, патча нет, но вы держитесь! С поиском незакрытых уязвимостей тоже все оказалось непросто. Топовые зарубежные сканеры ушли из России. Многие остались без эффективного инструмента – и мы в том числе, ведь наш облачный сервис контроля уязвимостей (VM, Vulnerability Management) был построен с использованием технологической платформы американского Qualys. В этом посте поговорим о том, как мы выбирали альтернативу Qualys, и что происходит с российским рынком сканеров уязвимостей сейчас. 

Сложно выстроить эффективную защиту ИТ-инфраструктуры, игнорируя процесс контроля уязвимостей (Vulnerability Management, VM). Он включает поиск и учет всех информационных активов, оценку уровня защищенности сетевой инфраструктуры и веб-приложений, разработку рекомендаций по исправлению обнаруженных уязвимостей и проверку выполнения этих рекомендаций. С одной стороны, этот процесс автоматизирован – слабые места ищет сканер. С другой – это ручная работа, так как на основе сканирования ИБ-специалисты приоритизируют множество найденных уязвимостей и устраняют в короткие сроки самые критичные. Именно поэтому крайне важно, чтобы экспертам было удобно читать и обрабатывать данные, которые выдает сканер. А как этого добиться – разберемся ниже.

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

Управляемые сервисы кибербезопасности – штука по определению автоматизированная и стандартизированная. Однако всегда найдется заказчик, которому сервис нужен «точно такой же, только меньше, но другой». И тогда появляются нетиповые решения и новые стандарты. В этом посте мы расскажем, как решали такие задачи при подключении сервиса защиты от сетевых угроз Unified Threat Management (UTM).

Соблюдение нормативных требований в области криптографии – вечная тема. Давно не менявшаяся нормативная база и возможность различной интерпретации формулировок порождают только споры и сомнения. С появлением сервисной модели в ИБ вопросов стало еще больше. Можно ли в принципе передать часть обязанностей по обслуживанию средств криптографической защиты информации (СКЗИ) сервис-провайдеру? Как это правильно оформить и чем потом подтвердить комплаенс? Попробуем разобраться в этом посте.  

Все, что описано ниже, затрагивает только защиту конфиденциальной информации. Защита государственной тайны отдельная тема и в статье не рассматривается.

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

Кадр из м/ф "Тайная жизнь домашних животных"

Подключение сервисов по информационной безопасности – штука занятная. Порой всего за 2 недели заказчик вдруг узнает много нового о жизни фауны своей инфраструктуры. Сложно сказать, что тут вызывает большее удивление: наглость особей «дикой природы» или неразумность «домашних» обитателей, которые на рабочем месте любят почитать предсказания Ванги на 2022 год, искренне верят в то, что швейцарская компания проводит оплачиваемые опросы, а также регистрируются на сайте yavirus.org.onion для получения 50% скидки в Яндекс.Еде. Сегодня вспомним несколько любопытных кейсов, с которыми нам пришлось столкнуться в прошлом году.

_{Кадр из м/ф "Крылья, ноги и хвосты"}

«Производительность данного оборудования в режиме шифрования – 100 Мбит/c», – гласит вендорский буклет/инструкция/сайт. Что означает эта цифра? В каких условиях она получена и чего ожидать пользователю на практике? В этом посте мы рассмотрим, что понимают под производительностью вендоры криптошлюзов, заказчики и операторы связи. Надеюсь, это убережет вас от ошибок в расчетах и пустых трат.

Согласитесь, в теме криптографической защиты информации больше вопросов, чем ответов. Как учитывать СКЗИ, как их хранить и перевозить? А если защиту надо установить на мобильное приложение, а сколько человек должны подписывать акт, надо ли создавать у себя в компании ОКЗИ, можно ли это сделать? И главное, все ли миллион лицензий вы получили или что-то забыли.

В этом посте мы собрали самые больные частые вопросы, которыми задаемся мы в «Ростелеком-Солар» и которые задают наши коллеги по цеху. Мы постарались найти на них ответы. Надеемся, будет интересно и, главное, полезно.

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

Не так давно на нас свалилась задачка: обновить криптошлюзы (КШ) «Континент» с версии 3.7.5 до версии 3.9.1 на всей VPN-сети довольно крупного клиента. Сеть географически распределена и охватывает все часовые пояса нашей необъятной Родины. Всего – порядка 120 центров управления сетью (ЦУС) с подчиненными КШ. В общей сложности нам предстояло обновить более 3500 «зелёных» устройств. Насколько нам известно, мы одни из первых выполнили обновление такого масштаба с версии 3.7.5 на 3.9.1 без замены железа и настройки сети «с нуля». То есть именно обновили существующую сеть со всеми ее текущими настройками и оборудованием. Но, как говорится, есть нюансы. Зная их заранее, вы наверняка сможете сэкономить свои ресурсы, если затеете нечто подобное.