Блог Сергея Борисова про ИБ

  Достаточно части организации задают вопрос – как построить процесс управления уязвимостями в организации. Недавно сообщество OWASP опубликовало документ Vulnerability Management Guide ( OVMG ) – по сути руководство по построению процесса управления уязвимостями. Давайте посмотрим подробнее на наиболее интересные моменты: ·         Чтобы “съесть” большого слона и не подавиться предлагается разделить его на маленькие понятные части ·         Поэтому общий процесс управления уязвимостями рассматривается как тройной цикл из подпроцессов, каждый из которых состоит из повторяющихся задач и подзадач o    Detection (Обнаружение) §   Define/Refine scope (Определение области применения) §   Optimize Tools (Оптимизация средств анализа) §   Run Vulnerability Tests ( Запуск тестов ) §   Confirm Findings (Подтверждение результатов) o    Reporting ( Отчетность )...

А помните в прошлом году один человек нашел баг в ГИС Минобра, выкачала базу дипломов, не смог связаться с администратором и опубликовал статью с примерами эксплуатации на Хабр? Под новый год ENISA (регулятор по ИБ евросоюза) опубликовал интересный документ по анализу и экономике процессов раскрытия уязвимостей - Economicsof Vulnerability Disclosure . В своем исследовании они опирались также на другой свежий документ - Software Vulnerability Disclosure in Europe от CEPS . В документе ENISA подробно рассматриваются возможные участники процессов поиска уязвимостей и раскрытия информации о ней.   Их мотивация, проблемы с которыми они сталкиваются и опасения. Рассматриваются текущие практики раскрытия и нераскрытия уязвимостей: В документе отмечается что развитие платформ bug bounty положительно повлияло на развитие процессов сообщения об уязвимостях, на привлечение внимания к теме уязвимостей. Средние стоимости вознаграждений. Но bug bounty пла...

ИБ сообщество почти не обратило внимания на недавнее информационное сообщение ФСТЭК России об уязвимости Intel Management Engine. А между тем значение оно имеет существенное значение для защиты ГИС и ИСПДн ( compliance ). Во-первых, для всех ИС, подключенных к сети Интернет, а таких подавляющее большинство, требуется применение средств обнаружения вторжений уровня сети и узла. Даже для ГИС К3 и ИСПДн УЗ 3-4. Во-вторых, для всех ИС, подключенных к сети Интернет, требуется применение межсетевого экрана типа “А”. Формально получается, что МЭ, сертифицированные по старым требованиям (которые разрешили использовать до модернизации ИС или переаттестации) уже не подходят. Только МЭ типа “ А ” сертифицированныепо новым требованиям  В-третьих, требуется в обязательном порядке обновить микропроцессорное ПО. Но сейчас такое обновление от Intel ещё отсутствует. А если судить по времени реакции конечных вендоров на предыдущуюуязвимость Intel ME , то это может затянуться ещё на + 6 ...

Продолжаем рассматривать недавние изменения в приказ ФСТЭК России №17. В этот раз – анализ уязвимостей ГИС. Теперь анализ уязвимостей ГИС требуется проводить на 3 из 6 этапах жизненного цикла системы защиты ГИС: формирования требований, внедрения и аттестации. 1. На этапе анализа угроз безопасности информации ГИС, необходимо провести анализ возможных уязвимостей ИС, используя при этом БДУ ФСТЭК России, а также иные источники данных об уязвимостях в качестве исходных данных. В модель угроз нужно включить описание возможных уязвимостей ИС. Основное отличие от других этапов кроется в слове “возможных”. Не фактических, а именно возможных. А при наличие хорошей фантазии, у нас будет возможно всё. На сколько я понимаю, тут нужна некая классификация всех возможных уязвимостей и исключение неподходящих типов уязвимостей по определенным причинам (отсутствие объекта воздействия, определенные структурные характеристики, неиспользуемые ИТ).  Проблема в том, что в БДУ ФСТЭК в...

Вводную часть вынес в отдельную статью чтобы не загружать читателей прописными истинами. Часть 2. К сути Так получилось, что каждая неожиданно опубликованная уязвимость в сертифицированном СЗИ обходится производителю достаточно дорого: ·          Если новая версия СЗИ находилась на сертификации (а это продолжительный процесс от 0.5 до 2х лет. Можно сказать, что у крупных производителей СЗИ всегда находятся на сертификации) и эта версия подвержена опубликованной уязвимости, то СЗИ автоматически снимается с сертификации и отправляется на доработку и потом на повторные испытания. В зависимости от сложности проблемы — это может отложить на 2-6 месяцев выход новой версии СЗИ на рынок. И время тут - деньги ·          Если СЗИ уже было сертифицировано, всё равно, после выпуска патча его надо отправить на инспекционный контроль, это дополнительные пара месяцев ожиданий и оплата услуг испытательной лабор...

Часть 1. Вводная (вынес сюда прописные истины, всем известные) До недавнего времени добропорядочные исследователи безопасности ( white hat ) фактически не занимались исследованиями безопасности российских средств защиты информации. Связано это было с рядом факторов: ·          важная часть нормативных документов (например, недавние требования к МЭ), требований регуляторов к СЗИ недоступна широкому кругу исследователей – доступ получают только разработчики СЗИ – лицензиаты ФСТЭК и ФСБ; а значит не заинтересованы в привлечении широкого круга лиц ·          испытательные лаборатории – только выполняют формальную проверку соответствия функций СЗИ – требованиям регулятора и в лучшем случае проходят сканнером уязвимостей. В детальном ручном поиске уязвимостей они не заинтересованы, так как основной показатель и критерий их работы (почему производители обращаются к данным ИЛ) это: быстрые сроки испытан...

На прошлой неделе ФСТЭК России опубликовал информационное сообщение об уязвимостях в СЗИ от НСД Secret Net и мерах по их нейтрализации. Подобное информирование от ФСТЭК по проблемам со средствами защиты информации случаются нечасто (прошлое было по ОС Windows 2003 год назад) поэтому давайте рассмотрим его подробнее: ·          основанием для сообщения послужила уязвимость в СЗИ Secret Net , зарегистрированная в БДУ - локальное повышение привилегий.      ·          уязвимости подвержены версии SN с 5.0 до 7 ·          для версий 6 и 7 уже выпущено обновление, устраняющее уязвимость ·          обновлений для версий 5.0 и 5.1 не планируется ·          для нейтрализации: для SN версии 5 и 5.1 необходимо обязательно перейти на 6 или 7, для версий 6, 7 – не...