Содержание. __ от редакции. Биография сетевого периметра в картинках
 Скачать 5.92 Mb.
|
|
72 74 76 78 80 82 84 86 88 90 92 94 96 98 100 102 02 04 06 08 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 СтатиСтика появления правил ids/ips suricATA ДЛя НОВыХ УгРОЗ Алексей Леднев habrahabr.ru/company/pt/blog/282029/ Обязательный атрибут защиты для большой компании — IDS/IPS (система обнаружения и предотвращения вторжений). На рынке большое количество коммерческих и open-source решений, и ка- ждое из них имеет свои достоинства и недостатки. Но общее во всех решениях — необходимость своевременного обновления правил обнаружения угроз. Большинство IDS/IPS позволяют использовать правила, разработанные для Snort. Одним из самых известных по- ставщиков правил является компания Emerging Threats, ставшая ча- стью Proofpoint. Мы решили собрать статистику по выпуску правил для наборов pro (коммерческая версия) и open (open-source версия) Emerging Threats для Suricata, так как их синтаксис аналогичен Snort, но при этом не- много расширен, что дает больше возможностей. Со страницы rules.emergingthreats.net/changelogs были собраны журналы обновлений правил suricata и suricata-1.3 начиная с 2015 года. Первое, что нас интересовало, — какое количество правил вы- пускалось для выявления эксплуатации уязвимостей. В эту категорию попали правила с привязкой к CVE, правила классов attack response и exploit. 0 100 500 400 600 700 800 900 1000 январь | 41 | 494 Количество правил для выявления эксплуатации уязвимостей Всего правил февра ль | 93 | 484 мар т | 55 | 711 апре ль | 57 | 690 май | 27 | 432 июнь | 39 | 810 ию ль | 43 | 672 авг ус т | 46 | 668 сент ябрь | 20 | 595 ок тябрь | 12 | 637 ноябрь | 41 | 629 дек абрь | 33 | 562 300 200 0 200 150 250 300 350 январь | 19 | 301 Количество правил для выявления эксплуатации уязвимостей Всего правил февра ль | 57 | 246 мар т | 30 | 254 апре ль | 31 | 226 май | 10 | 143 июнь | 7 | 241 ию ль | 10 | 172 авг ус т | 18 | 183 сент ябрь | 8 | 136 ок тябрь | 0 | 148 ноябрь | 6 | 185 дек абрь | 5 | 143 100 50 Статистика по набору eT pro за 2015 год Статистика по набору eT open за 2015 год Для привязки CVE к правилам мы распарсили актуальный файл sid- msg.map, а также журнал его изменений. Файл содержит маппинг sid-правил на их метаинформацию и имеет строки такого вида: 2021138 || ET WEB_SERVER ElasticSearch Directory Traversal Attempt (CVE-2015-3337) || cve,2015-3337 2021139 || ET TROJAN H1N1 Loader CnC Beacon M1 || url,kernelmode. info/forum/viewtopic.php?f=16&t=3851 CVE-идентификатор может содержаться как отдельно, так и в поле msg. Отсюда был получен маппинг CVE на правила. Поскольку одной атаке могут соответствовать несколько схожих правил, необходимо было делать выборку по уникальности правил. Правила, незначительно отличающиеся друг от друга полем msg (имеющие сходство больше 0,99 по алгоритму Джаро—Винклера), в выборку добавлены не были. В итоге были выбраны правила, содер- жащие маппинг с CVE или содержащие в поле msg один из следую- щих маркеров: attack response, exploit. 73 // уязвимости и атаки 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81 83 85 87 89 91 93 95 97 99 101 103 03 05 07 09 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 Как видно, в 2015 году количество правил, выпущенных для выяв- ления эксплуатации уязвимостей, не превысило 10%. Наибольшую площадь на диаграмме занимают правила для выявления сетевой активности вредоносных программ. Следующим шагом был сбор статистики покрытия правилами уяз- вимостей, опубликованных в 2015 году. Были отобраны уязвимости, имеющие удаленный вектор эксплуатации (AV:N) и CVSSv2-рейтинг больше 7,8. Из них мы отобрали те, для выявления эксплуатации кото- рых были выпущены правила. На диаграмме видно, что правилами покрывается лишь малая часть уязвимостей. Первая причина заключается в том, что часть CVE вы- пускается для случаев, которые невозможно (шифрованный трафик) или бессмысленно покрывать правилами (с выявлением и предот- вращением эксплуатации уязвимостей в веб-приложениях лучше справиться WAF, для правил же придется использовать громозд- кие регулярные выражения, что приведет к замедлению системы). Вторая причина в том, что не всегда известны подробности эксплу- атации уязвимости, и у экспертов нет образцов, на основе которых можно разработать правила. Итак, существует острая нехватка правил для актуальных уязвимо- стей. Одна из причин — нежелание вендоров, а также экспертов, находящих уязвимости и создающих правила для IDS/IPS, делиться техническими деталями обнаруженных уязвимостей. Для разработ- ки правил требуются образцы трафика с эксплуатацией уязвимости; при их наличии покрытие новых уязвимостей правилами увеличится в разы, и положение дел не будет таким плачевным. Соотношение правил из набора eT pro за 2015 год Соотношение правил из набора eT open за 2015 год 8% 25% 60% 2% 5% 4478 | Вредоносные программы 367 | Нарушения политик безопасности 133 | Правила на основе черных списков 1833 | Другие 573 | Эксплуатация уязвимостей 9% 25% 55% 5% 6% 1299 | Вредоносные программы 136 | Нарушения политик безопасности 130 | Правила на основе черных списков 585 | Другие 228 | Эксплуатация уязвимостей Статистика покрытия правилами уязвимостей 2015 года 0 200 150 250 январь | 3 | 51 Количество CVE, покрытых правилами февра ль | 25 | 86 мар т | 11 | 62 апре ль | 8 | 63 май | 13 | 102 июнь | 17 | 54 ию ль | 22 | 142 авг ус т | 8 | 123 сент ябрь | 8 | 109 ок тябрь | 7 | 159 ноябрь | 16 | 78 дек абрь | 15 | 196 100 50 Количество CVE с CVSS > 7,8 positive research 2016 74 52 54 56 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98 100 102 02 04 06 08 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 оценка уязвимоСтей CVSS 3.0 Сергей Рублев habrahabr.ru/company/pt/blog/266485/ Мы используем эту систему оценок с момента возникновения на- шей базы уязвимостей и первого нашего продукта — XSpider. Для нас очень важно поддерживать базу знаний, которую мы использу- ем в своих продуктах и услугах, в актуальном состоянии. Поскольку рекомендации по работе с CVSS-метриками не покрывают все возможные варианты уязвимостей, иногда приходится задаваться вопросом: «Как лучше проставить метрики, чтобы итоговая оценка отражала реальную опасность уязвимости?». Мы постоянно следим за развитием стандарта, поэтому давно жда- ли окончательной версии CVSSv3. Открывая спецификацию, я пре- жде всего хотел ответить на вопросы: «Что именно изменилось?», «Что стало лучше?», «Сможем ли мы использовать новый стандарт в наших продуктах?» и — поскольку к ведению базы часто подключа- ются молодые специалисты — «Как быстро можно овладеть мето- дикой оценки?», «Насколько четкими являются критерии?». В ходе изучения стандарта родилась эта статья, надеюсь, она помо- жет вам в освоении новой методики оценки уязвимостей. ВЕхИ В ИСТОРИИ CVSS Стандарт Common Vulnerability Scoring System был разработан группой экспертов по безопасности National Infrastructure Advisory Council. В эту группу вошли эксперты из различных организаций, та- ких как CERT/CC, Cisco, DHS/MITRE, eBay, IBM Internet Security Systems, Microsoft, Qualys, Symantec. В 2005 году состоялась первая публикация стандарта. Основные принципы расчета метрики уязвимостей, изначально заложенные в стандарт, сохранились и по сей день. Далее стандарт стал поддерживаться рабочей группой Common Vulnerability Scoring System-Special Interest Group (CVSS-SIG) в рам- ках проекта Forum of Incident Response and Security Teams (FIRST). Членство в группе не накладывает на ее участников каких-либо огра- ничений по поддержке и распространению стандарта. В 2007 году была опубликована вторая версия стандарта: были вне- сены правки в перечень показателей и изменена формула расчета итоговой метрики для более точной оценки опасности уязвимостей. В 2014 году рекомендации по использованию CVSSv2 выпускают та- кие авторитетные организации, как NIST и ITU, занимающиеся раз- работкой руководств и стандартов в области телекоммуникации и информационных систем. Использование метрик CVSS для оценки уязвимостей закреплено в стандартах PCI DSS и СТО БР ИББС. В июне 2015 года FIRST опубликовал финальную версию стандарта CVSSv3, о котором и пойдет речь в данной статье. ОСНОВы В CVSS входят три группы метрик: Базовые метрики описывают характеристики уязвимости, не ме- няющиеся с течением времени и не зависящие от среды исполнения. Этими метриками описывается сложность эксплуатации уязвимости и потенциальный ущерб для конфиденциальности, целостности и доступности информации. Временные метрики, как видно из названия, вносят в общую оценку поправку на полноту имеющейся информации об уязвимо- сти, зрелость эксплуатирующего кода (при его наличии) и доступ- ность исправлений. При помощи контекстных метрик эксперты по безопасности мо- гут внести в результирующую оценку поправки с учетом характери- стик информационной среды. Временные и контекстные метрики опциональны и применяются для более точной оценки опасности, которую представляет данная уяз- вимость для более или менее конкретной инфраструктуры. Значение метрики принято публиковать в виде пары из вектора (кон- кретные значения отдельных показателей) и числового значения, рассчитанного на основе всех показателей при помощи формулы, определенной в стандарте. НОВОВВЕДЕНИя В CVSSV3 Мы не будем подробно рассматривать CVSSv2, на эту тему есть доста- точно хорошая документация [6, 7], остановимся более детально на изменениях, вносимых новым стандартом. БАЗОВыЕ МЕТРИКИ Компоненты системы, для которых рассчитываются метрики В рамках стандарта вводятся следующие понятия: + уязвимый компонент (vulnerable component) — тот компо- нент информационной системы, который содержит уязвимость и подвержен эксплуатации; + атакуемый компонент (impacted component) — тот, конфи- денциальность, целостность и доступность которого могут по- страдать при успешной реализации атаки. В большинстве случаев уязвимый и атакуемый компоненты совпа- дают, но есть и целые классы уязвимостей, для которых это не так, например: + выход за пределы песочницы приложения; + получение доступа к пользовательским данным, сохраненным в браузере, через уязвимость в веб-приложении (XSS); + выход за пределы гостевой виртуальной машины. Согласно новому стандарту, метрики эксплуатируемости рассчиты- ваются для уязвимого компонента, а метрики воздействия для атаку- емого. В CVSSv2 не было возможности описать ситуацию, в которой уязвимый компонент и атакуемый различаются. 75 // уязвимости и атаки 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81 83 85 87 89 91 93 95 97 99 101 103 03 05 07 09 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 Метрики эксплуатируемости Вектор атаки Степень удаленности потенциального атакующего от уязвимого объекта. CVSSv2 CVSSv3 Название метрики Access Vector (AV) Attack Vector (AV) Возможные значения метрики Network (N) Network (N) Adjacent Network (A) Adjacent Network (A) Local (L) Local (L) Physical (P) Примечание: здесь и далее в скобках даются буквенные мнемоники, ис- пользуемые при описании CVSS-вектора. Изменения коснулись понятия «Local», которое в прошлых версиях стандарта описывало любые действия, не затрагивающие сеть. В но- вой версии вводится такое деление: + Local — для эксплуатации атакующему требуется локальная сес- сия или определенные действия со стороны легитимного поль- зователя, + Physical — атакующему требуется физический доступ к уязвимой подсистеме. Рассмотрим две уязвимости, имеющие одинаковую оценку с точки зрения CVSSv2 — 7,2 (AV:L/AC:L/Au:N/C:C/I:C/A:C). CVE-2015-2363 — Драйвер win32k.sys операционной системы Windows некорректно обрабатывает ряд объектов в памяти, что позволяет злоумышленнику, имеющему локальный доступ к системе, получить административные привилегии и выполнить произволь- ный код в режиме ядра. CVE-2015-3007 — Сетевые шлюзы Juniper серии SRX некорректно реализуют функцию отключения восстановления пароля неприви- легированным пользователем через консольный порт (set system ports console insecure). Уязвимость позволяет злоумышленнику, имеющему физический доступ к консольному порту, получить административ- ные привилегии на устройстве. Метрики для тех же уязвимостей по новому стандарту CVSSv3 различаются: Уязвимость Вектор CVSSv3 Оценка CVSSv3 CVE-2015-2363 AV:L /AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H 7,8 CVE-2015-3007 AV:P /AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H 6,8 Видно, что в CVSSv3 степень опасности уязвимости оценивается бо- лее точно, без усреднения, имевшего место в CVSSv2. Сложность эксплуатации уязвимости Качественная оценка сложности проведения атаки. Чем больше ус- ловий должно быть соблюдено для эксплуатации уязвимости — тем выше сложность. CVSSv2 CVSSv3 Название метрики Access Complexity (AC) Attack Complexity (AC) Возможные значения метрики Low (L) Low (L) Medium (M) High (H) High (H) «Сложность» сама по себе — понятие субъективное, поэтому данная метрика всегда трактовалась экспертами по-разному. К примеру, для уязвимостей, позволяющих реализовать атаку «Человек посереди- не», в базе NVD можно встретить различные варианты оценки Access Complexity. CVE-2014-2993 — Уязвимость в функции проверки SSL-сертификата приложения Birebin.com для операционной системы Android по- зволяет злоумышленнику осуществить атаку «Человек посере- дине» и получить доступ к конфиденциальным данным. [Access Complexity — Low] CVE-2014-3908 — Уязвимость в функции проверки SSL-сертификата приложения Amazon.com Kindle для операционной системы Android позволяет злоумышленнику осуществить атаку «Человек посе- редине» и получить доступ к конфиденциальным данным. [Access Complexity — Medium] CVE-2014-5239 — Уязвимость в функции проверки SSL-сертификата приложения Microsoft Outlook.com для операционной системы Android позволяет злоумышленнику осуществить атаку «Человек посе- редине» и получить доступ к конфиденциальным данным. [Access Complexity — High] Для облегчения толкования данной метрики в новом стандарте предлагаются только две ступени сложности и более четко пропи- саны критерии отнесения уязвимости к той или иной. В частности, уязвимости, позволяющие атаку «Человек посередине», предписано относить к категории High. Факторы, учитываемые в CVSSv2 метрикой Access Complexity, в новом стандарте учитываются двумя метриками — Attack Complexity и User Interaction. Аутентификация и требуемый уровень привилегий Требуется ли аутентификация для проведения атаки, и если требует- ся, то какая именно. CVSSv2 CVSSv3 Название метрики Authentication (Au) Privileges Required (PR) Возможные значения метрики Multiple (M) Single (S) High (H) Low (L) None (N) None (N) Подход к расчету метрики, основанный на количестве независимых процессов аутентификации, которые нужно пройти атакующему, недостаточно точно отражает смысл привилегий, необходимых для эксплуатации. Значение Multiple в базе NVD встречается достаточно редко и в ос- новном используется для уязвимостей, информация о которых недо- статочно детализирована. CVE-2015-0501 — Неизвестная уязвимость в Oracle MySQL Server позволяет удаленным аутентифицированным пользователям нару- шить доступность СУБД, используя неизвестный вектор, связанный с ‘Server : Compiling’. Значение Single не позволяет определить, требуется ли для эксплуа- тации доступ уровня привилегированного пользователя или доста- точно аутентификации стандартного пользователя. Рассмотрим две уязвимости, имеющие одинаковую оценку с точки зрения CVSSv2 — 9,0 (AV:N/AC:L/Au:S/C:C/I:C/A:C). CVE-2014-0649 — Cisco Secure Access Control System (ACS) некоррек- тно выполняет авторизацию при доступе к интерфейсу Remote Method Invocation (RMI), что позволяет удаленным аутентифициро- ванным злоумышленникам получить административные привилегии. positive research 2016 76 52 54 56 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98 100 102 02 04 06 08 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 CVE-2014-9193 — Innominate mGuard некорректно обрабатывает настройки Point-to-Point Protocol (PPP), что позволяет удаленным зло- умышленникам, имеющим ограниченные административные права, получить привилегии суперпользователя. Метрики для тех же уязвимостей по CVSSv3: Уязвимость Вектор CVSSv3 Оценка CVSSv3 CVE-2014-0649 AV:N/AC:L/ |