Устранение уязвимостей. Подход №2

Решил вернуться я к теме, поднятой неделю назад, относительно приоритезации устранения уязвимостей. Никита Ремезов в Фейсбуке справедливо заметил, что она ориентирована в первую очередь на госов и надо признать, что это так. К этой схеме он предложил добавить привязку к критичности сканируемых ресурсов для бизнеса. Да, и это тоже верно и контекстные метрики в CVSSv3 могут помочь это сделать. Преимуществом данной методики является ее простота. Чтобы ею воспользоваться не нужно ничего, кроме сканера безопасности, поддерживающего CVSS. Хотя даже он не нужен. Идентифицировать уязвимости можно либо путем анализа сетевого трафика

Список уязвимостей, идентифицируемых NGFW

либо использованием средств защиты ПК, которые часто имеют такие возможности.

Список уязвимостей, найденных на защищенных EDR узле

В последних двух случаях останется только выгрузить все данные об уязвимостях и провести их приоритезацию по описанной методике (это можно легко автоматизировать через обычный Excel).

Но что делать в крупных организациях, в которых десятки и сотни тысяч устройств. Даже если представить, что на каждом устройстве по одной уязвимости (а может быть и гораздо больше), то число строк в Excel станет неподъемным для анализа и составления списка дыр для устранения. Например, вот так выглядит картина всей сети Cisco, в которой насчитывает около полумиллиона устройств (200 тысяч пользовательских, около полусотни тысяч сетевых устройств, а также различные Интернет вещи).

Детализация карты сети сильно не улучшает ситуацию. Описанная в прошлой заметке методика не поможет в такой масштабной сети.

А надо ли это? Надо ли устранять все уязвимости? Даже те, у которых CVSS больше 6.5? А если попробовать пойти по иному пути и в scope работ по устранению уязвимостей включать не все, а только то, что может быть использовано извне? Вспомним историю с Equifax. Злоумышленники воспользовались уязвимостью на публичном Web-портале и через нее проникли во внутреннюю сеть бюро кредитных историй. Таких уязвимостей будет на порядки меньше и именно с них можно начинать устранение (по методике или без нее).

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

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

Интерес представляют только те уязвимости, которые позволяют путем многоходовой комбинации проникнуть внутрь. Именно их мы и будем устранять в первую очередь. Обратите внимание на иллюстрацию. Дыр внутри сети может очень много, но путь к ним всего один (отмечен красной линией). Устранив уязвимость в демилитаризованной зоне, мы получаем возможность существенно снизить плоскость будущей атаки, ограничив ее только ДМЗ.

Разумеется, для реализации данного подхода нам не обойтись уже только одним сканером . Придется использовать специализированные решения по построению векторов атак (у Cisco их нет - это не реклама :-), которые, анализируя настройки текущей инфраструктуры (сетевого оборудования и средств защиты), увязывают их с уязвимостями, и показывают масштаб будущих проблем. Для одной из точек выхода в Интернет в Cisco это выглядит так.

Методика из прошлой заметки дешева и не требует дополнительных затрат, но плохо работает в крупных инфраструктурах. Подход, описанный сегодня, более практичен, но и требует больших ресурсов / усилий по реализации. Зато полностью автоматизирован. Однако у него есть и еще один недостаток. Он предполагает, что мы не имеем других способов проникновения в корпоративную сеть или можем их минимизировать. Однако, если в сети есть незащищенный Wi-Fi, пользователи падки на подброшенные флешки, а руководство может безконтрольно приносить свои домашние ноутбуки и подключать их к внутренней сети, то второй подход может создать ложное чувство защищенности. Ищите баланс...

Подробнее…

Устранять или нет? Вот в чем вопрос!

Malotavr, который недавно вновь вернулся в эпистолярный жанр по ИБ, обратил свое пристальное внимание на тему управления уязвимостями (тут и тут). И это немудрено, учитывая место его работы - компанию Positive Technologies. Так сложилось, что и я недавно погрузился в эту тему, задавшись достаточно простым, на первый взгляд, вопросом - как приоритезировать уязвимости, которые надо устранять? Их могут тысячи и даже сотни тысяч в крупной инфраструктуре. Вариант "устранять все" в реальной жизни не работает. Пока мы устраняем одни уязвимости (в каком порядке? по времени? по критичности узла? по критичности уязвимости?), злоумышленники могут воспользоваться другими. Устраняя "другие", злоумышленники могут воспользоваться третьими. И так далее. Где провести ту грань, за которой уязвимость может быть отложена "на потом"?

Задавшись этим вопросом, я, случайно или нет, наткнулся на интересное исследование, в котором был проведен анализ списка CVE корпорации MITRE. Из 120 тысяч CVE были отброшены зарезервированные, отброшенные или еще обсуждаемые уязвимости - осталось 94457 дыр, по которым исследователи анализировали наличие эксплойта, в том числе и находящегося в диком виде. По результатам исследования были сделаны следующие выводы:

• 23% опубликованных уязвимостей имеют эксплойт.
• 2% уязвимостей имеют эксплойт в диком виде.
• Вероятность уязвимости быть использованной в 7 раз выше, если эксплойт существует. 
• 50% эксплойтов публикуется в течение двух недель после обнаружения уязвимости.

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

В ней я отталкиваюсь в первую очередь от общего рейтинга CVSS; затем смотрю на наличие эксплойта (либо из Банка данных уязвмостей ФСТЭК, либо из CVSS); потом на наличие удаленной эксплуатации дыры (параметр AV в CVSS), и, наконец, на сложность получения доступа (параметр AC в CVSS). Все значения берутся из полей БДУ. В реальной жизни для проверки наличия эксплойта и подтверждения CVSS обычно используются перекрестные базы (NVD, Secunia, ExploitDB, Cisco, Vulners и т.п.), но для ряда пользователей, особенно государственных, использовать зарубежные БД было бы не совсем правильно. К сожалению, наполнение БДУ пока не идеально (особенно в части оперативной информации по наличию эксплойтов), но другой возможности у госов нет (хотя тот же Vulners имеет российские корни, но "не признан" регулятором).

В итоге выстраивается приоритезация уязвимостей. Устраняются они исходя из наличия патчей или иных мер по устранению, включая компенсирующие. Если мер нет, то повторно проверяем через 2 недели (по статистике за 2 недели для большинства уязвимостей разрабатывается эксплойт). Если за месяц уязвимость не устранили, то начинается бессмысленное общение с разработчиком (госам проще - они могут пожаловаться во ФСТЭК для воздействия на разработчика) с попутной разработкой более эффективных компенсирующих мер. Если устранены все приоритетные уязвимости, то начинаем устранять неприоритетные. Ситуация, когда уязвимость не устраняется, отсутствует в принципе. Но процесс зациклен вокруг приоритетных уязвимостей в первую очередь, которые и представляют максимальную опасность.

Понятно, что у схемы есть и свои ограничения. Например, мы отсекаем локальные уязвимости без эксплойта с CVSS ниже 6.5, которые могут быть использованы злоумышленником, имеющим физический доступ к объекту защиты. Но тут я исхожу из предположения, что потребитель все-таки имеет хоть какие-то меры по контролю физического доступа, усложняющие эксплуатацию локальной уязвимости (хотя риск инсайдера остается). Также за двухнедельный временной зазор может быть разработан эксплойт и система может быть взломана. Можно попробовать уменьшить этот срок, но тогда мы слишком часто будем запускать цикл проверки, что для многих систем, особенно ГИС/МИС, будет непросто. Также я исхожу из того, что при отсутствии мер защиты безопасники все-таки смогут разработать компенсирующие меры (отключить уязвимую систему от сети, заменить уязвимое устройство, установить «виртуальный патч», зарезервировать систему, заблокировать использование уязвимости с помощью МСЭ или IDS и т.п.). Если нет, то тут уже ничего сделать нельзя :-(

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

Подробнее…

Взлом Equifax: разбор полетов

В августе Счетная палата США опубликовала отчет о результатах расследования нашумевшего взлома американского бюро кредитных историй Equifax, в результате которого злоумышленники получили доступ к персональным данным 145 миллионов граждан США, Канады и Великобритании.

Сам по себе взлом не представлял собой ничего необычного. В марте 2017-го года неизвестные злоумышленники использовали известную уязвимость на публичном Web-сайте для доступа к внутренним системам Equifax. В мае того же года злоумышленники стали красть данные из внутренних баз данных, пока 29 июля Equifax не обнаружила взлом и не блокировала действия злоумышленников.

Есть несколько интересных моментов, на которые я бы хотел обратить внимание в этой истории:

• Злоумышленники использовали известную к моменту первичной атаки уязвимость в Apache Struts Server, которая была идентифицирована US CERT двумя днями ранее. Это в очередной раз поднимает вопрос о том, как должен быть выстроен процесс устранения уязвимостей? Надо ли их устранять сразу по факту публикации бюллетеня по ним? А может надо ждать публикации сведений об экслойтах для уязвимости? Или опираться на рейтинг CVSS? Вопросов много, но однозначных ответов пока нет. В любом случае, это лишний раз напоминает нам, что злоумышленники далеко не всегда используют 0Day для своих атак.
• В процессе расследования выяснилось, что Equifax знал об уязвимости, так как получил от US CERT соответствующий бюллетень, который был распространен среди системных администраторов. Но... оказалось, что список этих лиц был устаревшим и в него не входили те администраторы, которые отвечали за установку патчей на уязвимом Web-портале. Наблюдается либо определенный пофигизм к поддержанию такой информации в актуальном состоянии, либо конфликт между ИТ и ИБ, что бывает очень часто.
• Интересно, что Equifax также заявил, что через неделю после получения бюллетеня от US CERT, они сканировали свою сеть, включая и уязвимый web-портал, но используемый сканер ничего не показал, что в очередной раз поднимает вопрос о том, надо ли целиком доверять используемым техническим решениям одного вендора и не надо ли их дублировать (не обязательно тратя на это еще деньги и используя решения open source).
• Equifax заявляет, что злоумышленники так долго могли скрывать свою деятельность, потому что использовали шифрование своей активности. Я уже неоднократно писал о том, что шифрование - это палка о двух концах и оно активно используется злоумышленниками для скрытия своих действий, существенно усложняя жизнь специалистам по ИБ. И им не нужно получать никаких лицензий ФСБ для этого. Так как это происходит все чаще, то необходимо иметь определенную стратегию для борьбы с зашифрованным трафиком.
• Самое интересное, что в процессе проведения регламентных работ в инфраструктуре Equifax выяснилось, что одно из решений по мониторингу и инспекции сетевого трафика не видело вредоносной активности в зашифрованном трафике из-за ошибок конфигурации этого устройства. Если быть точнее, то на данном устройстве был просроченный более чем 10 месяцев (!) цифровой сертификат. На мой взгляд это чистой воды халатность администраторов, которые почти год вообще не мониторили внутренний сетевой трафик. Это же показывает, что помимо защиты периметра необходимо иметь решения и для мониторинга аномалий во внутренней инфраструктуре. Без этого сегодня никуда.
• В другом источнике было написано, что используемое для инспекции сетевого трафика оборудование не соответствовали заявленным вендором цифрам по производительности, что часто приводило к задержкам в обработке трафика. В итоге настройки оборудования были изменены так (в сторону ухудшения ИБ), чтобы производительность устройства не снижалась.
• Никакой сегментации в инфраструктуре Equifax не было, что привело к неконтролируемому доступу к множеству различных баз данных, а не только к тем, которые были связаны с уязвимым Web-сервером. А ведь сегментация - это то, что дает чуть ли не 50% успеха в сетевой безопасности и при этом не требует особых затрат, так как задействует встроенные возможности сетевого оборудования.
• Интересный факт - позже выяснилось, что Equifax использовал оборудование компании FireEye для мониторинга угроз во внутренней сети, но FireEye на следующий день после известия о взломе Equifax удалил со своего сайта историю успеха о внедрении в кредитном бюро своих решений. Предположу, что это результат эмоционального решения руководства ИБ-вендора, который не хотел связывать себя с взломом, но мы все прекрасно понимаем, что кеш поисковых систем сохраняет все, в том числе и удаленные материалы. А на репутации такой факт сказывается гораздо больше, чем если бы мир знал, что Equifax защищался с помощью FireEye. Если верить отчету Счетной палаты США, то вина лежала целиком на администраторах Equifax, которые почти год не обновляли цифровой сертификат на средстве инспекции сетевого трафика. 

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

1. выстроить процесс управления уязвимостями и четко понимать, как и когда устранять обнаруженные уязвимости.
2. тесно контактировать с ИТ-командой, отвечающей за процесс управления патчами и иметь актуальный список лиц, которые занимаются устранением дыр.
3. мониторить внутренний трафик с помощью решений класса NTA (NBAD), которые позволяют обнаруживать аномалии и угрозы, проникшие из-за периметра или инициированные изнутри.
4. поддерживать актуальную конфигурацию как сетевого оборудования, так и средств защиты.
5. сегментировать сеть для предотвращения несанкционированного доступа. 
6. понимать риски использования злоумышленниками шифрования для скрытия своей активности и использования решений, которые борются с этим (EDR на оконечных устройствах, устройства для SSL Offload, инспекция DNS-трафика для обнаружения взаимодействия с инфраструктурой злоумышленников, использование технологий машинного обучения для обнаружения вредоносной активности внутри зашифрованного трафика без его расшифрования).

PS. Примечательно, но во взломе Equifax русских хакеров не обвиняли :-)

Подробнее…

Конференция ФСТЭК: финальный аккорд

Завершить рассказ (начало тут, тут и тут) о конференции ФСТЭК мне бы хотелось рассказом о некоторых докладах, которые запомнились (рекламные доклады я в расчет не беру). Начну с Конфидента, который в очередной раз порадовал хорошей аналитикой. В ноябре они в Питере уже делали очень хороший доклад на тему возможности (а точнее невозможности) выполнения требований по ИБ ФСТЭК (например, 17-го приказа) на базе отечественных ИТ-продуктов. В этот раз Конфидент, в лице Егора Кожемяки, рассказывал об устранении уязвимостей в сертифицированных средствах защиты информации. Первоначально была приведена статистика проект 0-DAY tracking project (www.zero-day.cz), который накапливает данные по ведущим мировым разработчикам ПО последние десять лет. Среднее время выпуска патча производителем составляет одни сутки. Тут стоит обратить внимание, что речь идет не об устранении уязвимости заказчиком, а о разработке патча вендором. Как показывает исследование Cisco среднее время присутствия уязвимости на стороне заказчика составляет... 5 (!) лет.

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

А вот статистика по устранению уязвимостей в сертифицированных операционных системах гораздо показательнее. Позволю себе скопировать подстрочник из презентации Конфидента, чтобы не пересказывать своими словами: "...заметен более длительный срок устранения уязвимостей в ОС. Если детально изучить выявленные уязвимости, то обнаружим, что подавляющее количество уязвимостей содержится в сторонних модулях (пакетах) т.н. свободного программного обеспечения, которые включаются в дистрибутив ОС".

"В 2017 году ситуация с обновлениями безопасности у Альт Линукс существенно изменилась в лучшую сторону. В 2016 году было 1 обновление, а в 2017 году их уже более 20 штук (и это не считая большого количества новостей по данной тематике)! Сроки устранения уязвимостей у Альт Линукс также на достаточно высоком уровне. Если не принимать в расчёт буквально несколько уязвимостей со сроком устранения 3 года (которые влияют на статистику), то среднее значение по срокам будет раза в 2 лучше. В статистике Альт Линукс встречаются уязвимости со сроком устранения буквально несколько дней. У Astra Linux Special Edition 1.5 также только одно обновление безопасности в 2016 году и только 3 таких обновления за 2017 год – скорость (частота) исправления уязвимостей существенно ниже по сравнению с Альт Линукс". Возвращаясь к разговору о том, что безопаснее, Windows или Linux, и может ли число уязвимостей говорить о незащищенности продукта, вспомню, что защищенность любого ИТ-решения, в т.ч. и сертифицированного, определяется не числом уязвимостей, а оперативностью их устранения, чем отечественные игроки пока похвастаться не могут (по сравнению с их зарубежными коллегами).

Второй запомнившийся мне доклад был сделан Суховерховым Александром из воронежского ГНИИ ПТЗИ ФСТЭК. Посвящен он был банку данных угроз и уязвимостей, которая активно развивается. Если не повторять цифр, то меня заинтересовал "Зал славы", в котором публикуются данные об организациях и частных лицах, которые активно исследуют защищенность различных ИТ-продуктов и сообщать о них в ФСТЭК. Каждому участнику, попадающему на сайт ФСТЭК, присваивается свой рейтинг, который и определяет место исследователей на "доске почета".

Хотя значения некоторых показателей вызывают у меня вопросы. Например, показатель важности объекта исследования. Почему BIOS важнее сетевого оборудования (чем, кстати, ПО сетевого средства отличается от сетевого программного средства)? А чем отличается программное средство АСУ ТП от ПО программно-аппаратного средства АСУ ТП? Наконец, почему ПО виртуализации важнее ПО СУБД? Ну да ладно.

Среди направлений совершенствования БДУ хотел бы выделить бесплатную утилиту ScanOVAL, которая предназначена для обнаружения уязвимостей ПО на платформе MS Windows.

В самое ближайшее время утилита появится на сайте ФСТЭК и будет доступна для всех желающих.

Утилита позволит загружать XML-файлы с OVAL-описанием уязвимостей, согласно которым будет происходить обнаружение уязвимостей на локальной машине (но только для Windows).

Во время секции вопросов и ответов Дмитрию Шевцову задали вопрос о том, какие РД/профили ФСТЭК выпустить в этом году. Дмитрий Николаевич ответил, что слишком много развелось "всяких блогеров", которые фотографируют планы ФСТЭК, публикуют их в Интернет, а потом критикуют и спрашивают, почему планы не выполняются :-) Одним из таких "блогеров" являюсь и я. Но я не буду спрашивать про обещанные на прошлогодней конференции ФСТЭК РД по СУБД, виртуализации и управлению потоками. Мне интереснее сейчас планы по развитию БДУ, которые были озвучены в прошлом году. Где база шаблонов ошибок для отдельных языков программирования и личный кабинет пользователя? Не успели их сделать в этом году :-(

На финал еще несколько прозвучавших тезисов:

• Заданный вопрос про методику моделирования угроз, обещанную еще в 2013-м году, мягко замылили, просто сославшись на необходимость использования БДУ и здравый смысл.
• В этом году, в начале второго полугодия, обещают не только упомянутый вчера РД по уровням доверия, но и РД по средствам борьбы с DDoS-атаками (для меня это было неожиданно - раньше этот тип средств ни разу не звучал на мероприятиях ФСТЭК).

В этом году на конференции не было Виталия Сергеевича Лютикова и поэтому всю тяжесть ведения взял на себя Дмитрий Николаевич Шевцов, который справился с непростой задачей модерирования конференции, которая, как обычно, проходила без перерыва (я упарился с 11 утра до 6 вечера сидеть) в плохо вентилируемом зале. Но несколько сотен человек сидело и слушало. Зал был набит битком и народ стоял даже в проемах и вдоль стен. И хотя после темы КИИ часть специалистов покинуло конференцию, до конца досидело все равно очень много людей.

ЗЫ. Мне кажется, что конференцию ФСТЭК логичнее было бы проводить в рамках InfoSecurity Russia. Организатор тот же, а аудитория гораздо более релевантная. Хотя если убрать "Актуальные вопросы защиты информации" из программы ТБ-Форума, то кто же туда ходить будеть?

ЗЗЫ. Конференция ФСТЭК - единственная на моей памяти (а их на ней много), на которой вообще не делается перерывов ни на обед, ни на кофе-брейк, ни вообще. 7 часов сплошных выступлений.

Подробнее…

7 гипотез об уязвимостях в ПО

Хочу продолжить начатую вчера тему про управление уязвимостями, но посмотреть на нее теперь с точки зрения производителя. Готовя вчерашний материал, я наткнулся на интересное исследование "An Empirical Analysis of Software Vendors’ Patching Behavior: Impact of Vulnerability Disclosure", которое базируется на изучении данных и статистики CERT/CC и SecurityFocus по уязвимостям. И хотя Университет Карнеги-Меллона, а именно его сотрудники являются авторами исследования, опубликовал его в 2006-м году, мне показалось, что озвученные в нем гипотезы имеют место быть и сейчас, спустя 10 лет с момента публикации.

Целью исследования было понять, как раскрытие информации об уязвимости, влияет на время ее устранения? К каким же выводам/гипотезам пришли авторы, проанализировавшие большое количество уязвимостей в самых популярных базах дыр того времени? Их несколько:

1. Раскрытие информации об уязвимости снижает время на ее устранение.
2. Крупные компании патчат свои продукты быстрее мелких.
3. Критические уязвимости патчатся быстрее менее приоритетных.
4. Публичные компании устраняют дыры в своих продуктах быстрее частных.
5. Уязвимости, попавшие в прицел CERT/CC, устраняются быстрее опубликованных в других источниках.
6. Уязвимости, раскрытые через CERT/CC, патчатся быстрее, чем дыры, опубликованные CERT/CC, но раскрытые ранее через иные источники.
7. Мнение о том, что в open source продуктах уязвимости патчатся быстрее, чем в проприетарном ПО, не нашло подтверждения.

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

Не могу сказать, что приведенные гипотезы открыли неизвестные миру истины. Скорее они подтвердили с цифрами в руках известные ранее предположения. Мне показались заслуживающими внимания 2-я и 4-я гипотезы. Они говорят о том, что небольшие игроки рынка, и уж тем более компании частные, менее зависимы от мнения окружающих и поэтому работают на поле устранения уязвимостей хуже их более публичных и более крупных "коллег".  Отсюда вытекает вывод, что у них процедура SDLC обычно выстроена гораздо хуже и соответственно уязвимостей в их решениях больше и устраняются они дольше (если вообще обнаруживаются).

Думаю, что я мог бы добавить сюда еще одну гипотезу - в продуктах крупных или широко известных компаний уязвимости ищутся чаще, чем в непопулярных или навязанных (например, законодательством) решениях. Именно ищутся, а не находятся. Почувствуйте разницу между этими двумя понятиями. Понятно, что на более популярные продукты усилия исследователей бросаются чаще и больше, чем на мало кому известное ПО и оборудование. Помогает этому и запускаемые некоторыми крупными игроками программы Bug Bounty.

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

Подробнее…

Среднее время неустранения уязвимостей пользователями - 5 лет!

Как вы думаете, сколько времени проходит с момента появления информации об уязвимости и ее закрытием со стороны производителя? А сколько времени уязвимость не закрывается потребителем уязвимого ПО или инфраструктурного оборудования, даже несмотря на наличие выпущенного и бесплатно доступного обновления? В последнее время тема управления уязвимостями находит все большее отражение и в нормативных документах (ФСТЭК на эту тему не только разделы в своих приказах поместил, но и целые ГОСТы разработал, а ЦБ выпустил отдельную РС и добавил требования в свое обязательное 382-П и ряд других документов) и в средствах массовой информации.

Вопреки расхожему мнению о дырявости многих продуктов - корпоративных и обывательских, прикладных и инфраструктурных, статистика говорит обратное. Против 84% уязвимостей производители выпускают патчи в первые 24 часа с момента опубликования сведений о дыре. такова статистика за 2015-й год по данным компании Flexera (в упоминаемом ниже исследованиях Cisco схожие цифры). В прошлом году этот показатель был равен 83%, а в 2010 - всего 49%.

Иными словами, всего за 5 лет в среде разработчиков произошел качественный скачок в деле устранения обнаруживаемых уязвимостей. Я не раз утверждал и продолжаю утверждать, что защищенность ПО и железа определяется не числом дыр в нем (этот показатель говорит в первую очередь о популярности продукта), а выстроенным процессом их устранения. Наличие формализованного SDLC у многих производителей позволили существенно улучшить показатель выпуска патчей за прошедшие 5 лет. Но заказчиков по-прежнему ломают. Почему?

И вот тут мне бы хотелось сослаться на полугодовой отчет Cisco по кибербезопасности, который мы выпустили (в том числе и на русском языке) в конце этого лета, в котором приводится очень интересная статистика. Среднее время присутствия уязвимости на стороне заказчика составляет... 5 (!) лет. Пять лет!

Это проблема и системного ПО, и инфраструктурного. У последнего показатель выше, так как его обновляет гораздо реже, живя по принципу "работает - не трогай". Понятно, что обновить тот же браузер, офисное ПО или даже Web-сервер проще, чем маршрутизатор или межсетевой экран, на который завязано слишком много. Отсюда и вытекает парадокс - производитель выпустил патч для обнаруженной уязвимости, а потребитель не спешит его устанавливать.

И проблема эта общемировая. У кого-то ситуация чуть лучше, у кого-то чуть хуже, но все регионы мира сталкиваются с тем, что потребители используют устаревшее оборудование:

 и ПО:

увеличивая окно возможностей для злоумышленников, которые могут годами "резвиться" в сетях своих жертв, не опасаясь, что им "перекроют кислород". В 2015-м году мы проверили 115 тысяч устройств Cisco по всему миру и 92% из них содержали известные уязвимости для которых были выпущены исправления. В среднем на каждом устройстве присутствовало 28 (!) уязвимостей. В процессе анализа на десятой части всех устройств были найдены уязвимости известные более 10 (!) лет. Более десяти лет!!! Только вдумайтесь в эту цифру. 

При этом ситуация усугубляется еще и тем, что число уязвимостей в устаревшем ПО и железе не ограничивается одной дырой. Обычно их гораздо больше. По уже приведенным выше данным Cisco в сетевом оборудовании таких дыр обычно около трех десятков. В среднем же на один ИТ-актив приходится около 7 уязвимостей. Об этом говорит отчет Nopsec за этот год. Облачные провайдеры обычно более уязвимы - каждый их актив содержит в среднем 18 уязвимостей. Активы финансового сектора, при средней длительности устранения уязвимости в 176 дней (очень хороший показатель по сравнению с 5-тью годами), обладают 6-тью уязвимостями; ВУЗы - двумя...

Понятно, что указанные цифры - это средняя температура по больнице - у каждого потребителя ситуация может меняться. Более того, она меняется в зависимости от того, о каких уязвимостях мы говорим. Например, по данным Nopsec, среднее время устранения уязвимостей во внутренних сетях вдвое ниже, чем на периметре (а мы в своем исследовании преимущественно оценивали внешние устройства), и в 5 раз выше, чем у Web-приложений. У "пользовательского" ПО ситуация тоже сильно меняется. Например, у Google Chrome, с его обязательным автоматическим обновлением и необходимостью иметь права администратора для отключения автообновления, обновления "накатываются" оперативно и за небольшой промежуток времени, пользователей переводят на новую версию ПО, с устраненными уязвимостями. Более того, Google не разрешает скачивать устаревшие версии браузера ни со своего, ни с посторонних сайтов. Это дает свой эффект.

Чем жестче политика производителя, тем эффективнее результат. Например, у Microsoft Office функция автообновления хоть и присутствует, но большинство пользователей игнорирует ее, эксплуатируя одну и ту же версию годами. Выход новой версии "Офиса" никак не сказывается на динамике обновлений, что само по себе парадоксально.

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

В нашем отчете приводится несколько причин такого безалаберного поведения:

• Нет денег на обновление (если речь идет об обновлении основных версий)
• Боязнь изменений в функциональности ПО
• Обновление может привести к простоям в работе организации
• Объединение обновлений безопасности с функциональными обновлениями.

В отчете Nopsec к этому списку добавляются:

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

От себя могу добавить еще одну причину, которую никто и никогда не называл в зарубежных отчетах, но которая заслужила второе место в моем опросе, который я запустил в августе в Twitter. Боязнь потери сертификата для российских пользователей - это серьезнейшая причина, почему не нужно обновлять уязвимое ПО. Дилема "уязвимое, но с бумажкой, или защищенное, но без сертификата", к сожалению, имеет место быть и как ФСТЭК не старается исправить эту ситуацию, пока до положительных сдвигов далеко.

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

Подробнее…

Heartbleed, атрибуция кибератак и бритва Хенлона

Давно хотел написать эту заметку, но все как-то руки не доходили. Но после почти месяца пребывания в США тема всплыла вновь и теперь я уже не могу про нее не написать. Но сначала я задам риторический вопрос: "Кто стоит за уязвимостью Heartbleed?" Отдельные чудаки, как это часто бывает, безапелляционно скажут, что это АНБ внедрило уязвимость, которой были подвержены сотни тысяч узлов в Интернет. Я же, известный агент вашингтоновского обкома, расширю этот список (несанкционный) следующими кандидатурами:

• ФСБ. А почему бы и нет? Если уж наша спецслужба манипулирует мочой спорстменов и выборами американского президента (и непонятно, что еще сложнее), то что ей мешает внести правки в код OpenSSL?
• Криминал. Тоже вариант. OpenSSL крутится на многих финансовых ресурсах, которые могут представлять интерес для злоумышленников, которые могли подкупить разработчиков OpenSSL или самостоятельно внести уязвимость в код.
• Обиженный фанат open source community, которого отшила подружка на день Рунета (а именно в этот день была опубликована информация о Heartbleed).
• Инопланетяне. Ну а почему бы и нет? При отсутствии доказательств их несуществования тоже вполне себе версия; не хуже и не лучше других.

Аналогичный вопрос об авторстве может возникнуть и в отношении кибератак. Сами по себе они врядли возникают (а уязвимости могут, но об этом ниже). Поэтому вопрос об атрибуции киберугроз встает достаточно остро. У нас часто обвиняют американцев, а те в свою очередь, а за ним и европейцы, любят обвинять во всех своих кибер-бедах китайцев и русских. Но на чем каждая сторона основывает свои доводы? На принципе геополитической целесообразности. Ничего другого пока за этими обвинениями нет.

В последний месяц-другой было очень много обвинений России в кибератаках. То на Демпартию США, то на WADA, то на спортивный арбитраж, то на NY Times, то даже на само АНБ... Тут впору вспомнить известный старый фильм "Красная жара" с Шварцнегером:



Юный инноватор (таким званием он был награжден) из американской CrowdStrike, ее основатель и технический директор, Дмитрий Альперович, изучавший взлом демократов, дословно написал в своем исследовании: "Extensive targeting of defense ministries and other military victims has been observed, the profile of which closely mirrors the strategic interests of the Russian government, and may indicate affiliation with Главное Разведывательное Управление (Main Intelligence Department) or GRU, Russia’s premier military intelligence service". То есть вывод о русском следе сделан на основании того, что среди жертв были преимущественно военные организации, и атаки происходили с IP-адресов, зарегистрированных за Россией.

В отчете ThreatConnect, названном "Все дороги ведут в Россию", чуть больше деталей деятельности хакера(ов), скрывающихся под именем Guccifer. Опираясь на информацию о владельцах ряда адресов, участвующих в атаке на демократов, и используемый русскоязычный интерфейс, был вновь сделан вывод о русском следе. Тут не могу опять не вспомнить очередное творение советского периода - книгу "Тайна Фенимора" и снятый по ее мотивам фильм "Три веселые смены". Там был такой фрагмент:

"Но неожиданно Ира Привалова спросила Женю Рыжика:
– А кто такой Фенимор?
– Не знаю… – неуверенно сказал мальчик и тут же поправился: – Писатель такой… Фенимор… Купер.
– Странно, – сказала вожатая, – сегодня во сне ты произносил это имя. Может быть, тебе приснился Фенимор Купер?…
Писатель? – Не знаю. Может быть, и приснился. Какое это имеет значение.
Ира Привалова сурово посмотрела на Женю Рыжика.
– Штабс-капитан Рыбников во сне заговорил на родном японском языке, и это выдало его как японского шпиона. Во сне человек может открыть свою тайну.
С этими словами она встала и пошла прочь.
– Нет у меня никаких тайн! – вслед ей крикнул Рыжик."

Если бы я был русским хакером, работающим на ФСБ, то я специально бы выбрал для своей деятельности сайт, у которого только один интерфейс, на русском; чтобы он уж точно вел все следы в Россию (это была шутка). Хотя в ThreatConnect на полном серьезе считают, что использование русского VPN-сервиса через французскую инфраструктуру - это фирменный знак российских спецслужб :-) Помимо ThreatConnect, а они написали целых 9 статей на тему взлома "русскими хакерами" американских демократов, этот кейс разбирали в Mandiant, известной своей любовью к России, и Fidelis. Уровень их доказательств примерно такой же и в качестве основа атрибута в своих выводах они опираются на "русские" IP-адреса.

Пресса тоже сходится в мнении, что за последними атаками стоят русские хакеры, ассоциированные с государством. Мотивация журналистов проста - а кто еще, кроме России, которая имеет большой опыт влияния на внутреннюю политику по всей Европе? Например, в Independent это обосновывается так: "And who was responsible for the leak? Almost certainly, experts say, the Russians, directly or indirectly. For one thing, the Kremlin has a long record in doing this sort of thing, meddling in internal politics across Europe. Back when the DNC hack became public, in mid-June, Russian agents were identified as prime suspects".

Однако, если отбросить всю эту околополитическую шумиху, то на самом деле провести реальную атрибуцию киберугроз сегодня очень затруднительно. Я в прошлом году писал большую статью на эту тему, в которой постарался показать, что существует множество причин организационного, правового, коммерческого, геополитического, психологического плана, которые мешают адекватной атрибуции. И это еще мы не рассматриваем ситуацию, когда злоумышленники осознанно фальсифицируют якобы "доказательства" своей деятельности, призванные направить исследователей по лживому следу. Например, Лаборатория Касперского обнаружила такие факты в отношении кампании CloudAtlas и хакерских групп Lazarus и Sofacy. Понимая всю сложность атрибуции ЛК отказалась от того, чтобы указывать авторство вредоносных программ и кампаний, которые они расследуют. И многие специалисты (а не балаболы, гонящиеся за дешевой популярностью) сегодня стараются следовать этой практике.

Например, известный эксперт по кибербезопасности промышленных систем Роберт Ли, известный своей русофобией, часто называл Россию в качестве основного источника современных киберугроз. Я с ним даже спорил на эту тему и в Интернете и на курсах SANS, на которых он был моим инструктором. После неоднократных дискуссий на эту тему он перестал огульно обвинять Россию, сменив риторику на более спокойную. В частности в своей мартовской статье, он подробно описывает все сложности атрибуции киберугроз и просит не считать его прежние высказывания о том, что за атаками на энергосистему Украины стоит Россия, верными. Более того, он пишет, что доказательств этого нет и скорее всего не будет найдено, с чем я тоже соглашусь (если не будет какого-либо перебежчика, который раскроет, кто же все-таки стоял за этой атакой).

Завершить свою длинную заметку мне хотелось бы возвратом к тому, с чего я начал. Помимо названных пяти вариантов появления Heartbleed есть и шестой, который лично мне представляется наиболее вероятным. Называется он "бритвой Хенлона", за которой скрывается известная фраза "Никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью". По данным компании Black Duck 67% компаний в мире не анализируют уязвимости в open source. И с OpenSSL ситуация была именно такой - этот проект поддерживался в инициативном порядке всего двумя разработчиками, занимающимися этим неполный рабочий день. Стоило ли в таких условиях ждать, что они будут заниматься безопасностью модуля по безопасности?

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

Подробнее…

Уязвимость или закладка? В чем разница?

На волне последних новостей о Shadow Broker и частично выложенным в открытый доступ, а частично выставленном на продажу наборе вредоносного ПО, мне хотелось бы вспомнить о терминологии. А то что-то внезапно и много развелось специалистов по закладкам. Особенно в среде специалистов по поиску уязвимостей. Причем некоторые подменяют понятия "уязвимость" и "закладка" непреднамеренно, а некоторые делают это осознанно, манипулируя терминами в своих интересах, зачастую коммерческих.

Итак, я приведу три определения (в разницу терминов defect, fault, failure, error и сленгового bug вдаваться не буду - они сейчас они имеют никакого значения):

1. Уязвимость - свойство информационной системы, обусловливающее возможность реализации угрозы безопасности обрабатываемой в ней информации (ГОСТ Р 50922-2006 "Защита информации. Основные термины и определения"). В ГОСТ Р 56545-2015 "Защита информации. Уязвимости информационных систем. Правила описания уязвимостей" определение немного другое. Там уязвимость - это недостаток (слабость) программного (программно-технического) средства или информационной системы в целом, который может быть использован для реализации угроз безопасности информации. В ГОСТ Р 56545 есть еще и определение zero day, но дела это не меняет. Иными словами речь идет об ошибке в ПО или ИС, которая может привести к угрозе ИБ. Возможность реализации угрозы и разделяет ошибки и уязвимости, которые в большинстве случаев являются подмножеством ошибок.
2. Программная закладка - это преднамеренно внесенный в программное обеспечение функциональный объект, который при определенных условиях инициирует реализацию недекларированных возможностей программного обеспечения. Это определение из ГОСТ Р 51275-2006 "Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения". Аналогичное определение и в более старом ГОСТ Р 50.1.053-2005 "Информационные технологии. Основные термины и определения в области технической защиты информации". В РД ФСТЭК по недекларированным возможностям определение схожее - "программные закладки – преднамеренно внесенные в ПО функциональные объекты (то есть элементы программы, осуществляющие выполнение действий по реализации законченного фрагмента алгоритма программы), которые при определенных условиях (входных данных) инициируют выполнение не описанных в документации функций ПО, приводящих к нарушению конфиденциальности, доступности или целостности обрабатываемой информации".
3. В свою очередь "недекларированные возможности" это, согласно ФСТЭК, функциональные возможности ПО, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации. Реализацией недекларированных возможностей, в частности, являются программные закладки.

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

Поскольку в последнее время речь идет о известных и ранее неизвестных слабостях в ПО различных производителей, которые могли эксплуатироваться упоминаемыми в опубликованных материалах Shadow Broker программами, то речь идет об уязвимостях (и уязвимостях нулевого дня), но никак не о закладках. В противном случае почти все 15 тысяч уязвимостей в базе данных ФСТЭК можно тоже отнести к разряду закладок. В том числе и бреши в ПО отечественных производителей, которые, имея лицензии ФСТЭК или ФСБ, могут быть обвинены в тесных связях со спецслужбами, которые в свою очередь внедрили эти закладки для несанкционированного доступа к защищаемым системам. А почему бы и нет? Логика по крайней мере та же, что используют отдельные "эксперты", так прям и пышущие желанием найти в каждой становящейся достоянием гласности уязвимости злой умысел производителя или американских спецслужб. Желание попиариться или присосаться к государственным деньгам понятно, но стоит и просчитывать последствия своих высказываний, которые могут быть повернуты и против "экспертов", в продуктах которых могут быть тоже найдены уязвимости, которые тоже могут быть названы происками американского АНБ, российской ФСБ, белорусского КГБ, казахского КНБ и множества других структур, оканчивающихся на вторую букву русского алфавита.

ЗЫ. Кстати, Шнайер считает, что вторая часть архива Shadow Broker - это фейк, и цель была опубликовать именно первую с целью демонстрации своей мощи неизвестными хакерами, за которыми, по версии того же Шнайера, стоит... Кто бы вы думали? Да, опять Россия или, с меньшей вероятностью, Китай.

Подробнее…

Государственная bug bounty и биржа по продаже уязвимостей

На прошлой неделе Коммерсант опубликовал заметку о созданной в России бывшим сотрудником Росфинмониторинга бирже уязвимостей. Расположена она на англоязычном сайте, не имеющем никакой русскоязычной страницы. При этом среди потенциальных покупателей называются госорганы (интересно какого государства, если наши по английски не очень общаются?) и ИБ-компании. Средняя цена, которую биржа готова платить за уязвимость в ОС, браузерах, продуктах Adobe и MS Office - 50 тысяч долларов США. За уязвимости в Web-приложениях предлагают "всего" 15 тысяч долларов, а за дыры в Tor - целых 80 тысяч.

В этой новости лично у меня подозрения вызывает два момента. Первый - цена. На западных аналогичных площадках за аналогичные уязвимости платят больше (на черных биржа тем более). Второй - целевая аудитория. Российские ИБ-разработчики покупать такие дыры не будут (дорого и не зачем), а отечественные пентестеры помимо "дорого и не зачем" и сами обладают квалификацией для поиска дыр и разработки эксплойтов. Они скорее могут быть продавцами, а не покупателями. Да и цена одной дыры сопоставима со стоимостью контракта на пентест (где экономика?). С отечественными госорганами ситуация еще сложнее - они врядли будут покупать такую информацию на бирже; они обязаны будут проводить такие сделки через госзакупки со всеми вытекающими отсюда последствиями и публичностью. Например, достаточно вспомнить про конкурс "Исследование возможности получения технической информации о пользователях (пользовательском оборудовании) анонимной сети ТОR", шифр — "ТОР (Флот)", стоимостью 3,9 миллиона рублей (112 тысяч долларов на момент размещения заказа). Или конкурс "Создание аппаратно-программного комплекса по проведению негласного и скрытого удаленного доступа к оперативно значимой информации на целевой электронно-вычислительной машине" (шифр — "Хамелеон-2 (Флот)") за 20 миллионов рублей. Все они были публичны.

Однако гораздо интереснее оказалась вторая новость, связанная с биржей уязвимостей. Речь идет об озвученной вскользь заместителем министром связи и массовых коммуникаций на форуме Института развития Интернет (ИРИ) "ИТ+Суверенитет" идее запуска государственной программы bug bounty, то есть тоже покупке информации об уязвимостях в программном обеспечении, но под контролем государства.

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

Правда, Минкомсвязь говорит о системе грантов, что немного отличается от идеи bug bounty. И опять же непонятно, за чем счет планируется банкет? Если это деньги не государства, то причем тут Минкомсвязь? Не идет ли тут речь об обязательном внедрении программ bug bounty для разработчиков ПО, попадающего в реестр Минкомсвязи? Тогда сразу отпадает вопрос "откуда деньги". Вообще вопрос качества и безопасности этого ПО давно стоит на повестке дня, но Минкомсвязь от него все время дистанцируется, считая, что это не совсем их тема. А тут вдруг поворот на 180 градусов.

И при этом у меня возникает закономерный вопрос. А что с банком данных угроз и уязвимостей, который создала и поддерживает ФСТЭК? Ведь у нас ФСТЭК была первой, кто задумалась о качестве кода и даже разработала стандарт по безопасной разработке ПО. Потом был Банк России со своей РС по жизненному циклу АБС с точки зрения ИБ. Но ФСТЭК не навязывает эти требования, прекрасно понимая, что это не такая простая задача, как кажется. И банк уязвимостей ФСТЭК ведет по своей инициативе и за свой счет. На последнем PHDays эту тему уже поднимал начальник 2-го Управления ФСТЭК Виталий Сергеевич Лютиков. Он приглашал исследователей к сотрудничеству, но в социальных сетях его раскритиковали, желая денег за раскрытие дыр.

Идея с "государственной bug bounty" как раз отвечает на вопрос исследователей и позволяет им заработать. То есть идея, озвученная заместителем министра вполне здравая. Ее только допиливать надо и четко проработать механизм реализации с привлечением всех заинтересованных госорганов (ФСТЭК и, возможно, ФСБ с Банком России). Не стоит Минкомсвязи влезать в эту тему в одиночку - опять получится не совсем то, что должно быть.

Подробнее…